A large organisation has thousands of users, hundreds of systems and tens of thousands of access permissions. An employee who was in the credit department five years ago and now works in marketing probably still holds the old entitlements. A contractor whose project ended may still have an active account. Service accounts created for a temporary integration remain for years with an unchanged password. None of these is a disaster on its own, but together they create a level of risk that no auditor will overlook and no security team can manage by hand.
Separating two concepts is essential here. Identity and access management (IAM) answers the question of whether this person is who they claim to be and whether they are allowed to do this right now: authentication, single sign-on, multi-factor verification and token issuance. Identity governance and administration (IGA) addresses a deeper question: whether this person should have this access at all, who approved it and when it must be reviewed. Organisations that have only IAM lock the front door well but have no record of who was given a key.
The preferred architecture designs the two as complementary layers over one shared identity source. At the centre sits an identity directory fed by the HR system and the party master, following each identity through its lifecycle from joining to leaving. The IAM layer, built on open standards such as OpenID Connect and SAML, handles authentication and token issuance for every application, API and agent. The IGA layer manages roles, policies, request-and-approval workflows, periodic access reviews and segregation of duties, and provisions the outcome as concrete entitlements into target systems.
The first practical consideration is designing the role model. Roles must be derived from the real structure of the organisation and from job descriptions, not from existing access; otherwise all the accumulated excess permissions of the past are formalised as roles. A workable approach combines base roles assigned by unit and position with individually requested entitlements. For example, every branch employee automatically receives the branch base role, but access to approve facilities above a defined threshold requires a request, a manager's approval and an expiry date.
The second consideration is automating the lifecycle. The most effective security control is removing access on time, and that is only reliable when it is wired to HR events. When an employee's record changes to leaver status, accounts must be disabled, tokens revoked and entitlements withdrawn at that moment. A transfer between units must remove the old role and grant the new one, not merely add the new one on top. This event-driven linkage shifts the security team's workload from manual review to supervising exceptions.
The third consideration is non-human identities. Services, scheduled jobs, IoT devices and, increasingly, AI agents all need an identity, an entitlement set and a named owner. These identities must go through the same lifecycle and the same periodic review as human users. An agent acting on behalf of a user should hold a token with narrow scope and short lifetime, and every action it takes should be attributed to both identities, the agent and the user, so the audit trail never loses either.
The pitfalls in this field are plentiful. First, starting with a tool instead of with the data model and the process; no product can define roles that nobody has defined. Second, ceremonial access reviews in which managers approve everything unread; the remedy is showing context, such as when each entitlement was last used, and keeping each review short. Third, ignoring legacy systems without standard interfaces that are still managed through files and direct database access. Fourth, bundling IAM and IGA into one enormous project that loses credibility before it delivers its first value.
At Niadad, the Shanasa platform («شناسا») provides the identity and access layer on open standards: central authentication, single sign-on, multi-factor verification and token issuance for users, services and agents. The Parsa platform («پارسا») takes the policy and governance layer: role and access-policy definition, request-and-approval workflows, periodic reviews and segregation of duties. In Niadad's banking programme these two sit beside the Ashna party master and the API gateway, so that identity is managed as one coherent chain from source to point of enforcement.
Enterprise security ultimately comes down to one simple question: can you say, at any moment, who has access to what and why? IAM answers the who; IGA answers the why. An organisation that has both not only passes its audits but can confidently open its systems to new users, partners and agents without losing control. The work is never finished, because organisations keep changing; but with the right architecture, keeping up becomes routine rather than a periodic emergency.