IAM is the layer that decides who exists in your systems, what each of them is allowed to touch, and what happens to that access the day someone leaves.
The short answer
IAM stands for identity and access management. It covers the full lifecycle of an account: creating it, authenticating it, authorising what it can reach, reviewing that entitlement periodically, and revoking it on exit. Every framework audits it, and it is the control set most likely to fail an audit through neglect rather than through a missing tool.
Most teams buy authentication and assume that covers IAM. Authentication proves who is asking. It says nothing about whether that person should still have production access eighteen months after moving to a different team.
On this page
The IAM lifecycle
Four stages. Companies invest heavily in the first two and almost nothing in the last two, which is exactly the wrong distribution because the risk sits at the end.
What IAM is made of
| Component | What it does |
|---|---|
| Directory | The authoritative list of who exists, usually synced from the HR system so joiners and leavers flow automatically |
| Single sign-on | One authentication event across many applications, which also gives you one place to switch access off |
| Multi-factor authentication | A second proof beyond the password, the single highest-value control in the whole set |
| Role-based access | Permissions attached to a job function rather than to a person, so access changes when the role does |
| Privileged access | Separate, tighter handling for administrator and root credentials, usually time-bound and recorded |
| Access reviews | A scheduled recertification where an owner confirms each entitlement is still needed, with a record either way |
| Audit logging | Sign-ins, privilege changes and failed attempts fed into the SIEM for correlation |
Where IAM fails audits
| Finding | What it looks like in practice |
|---|---|
| Orphaned accounts | Credentials still active weeks after an exit, usually in a tool outside the SSO directory |
| Privilege accumulation | Access granted for a project three roles ago and never withdrawn |
| Shared administrator credentials | One root login several people use, so no action can be attributed to a person |
| Unevidenced reviews | A review that happened in a meeting with no artefact, which an auditor records as not performed |
| Unmanaged service accounts | Machine identities with standing keys, no owner, and no rotation schedule |
| Shadow applications | Tools bought on a card, holding company data, outside the directory entirely |
Reviews need artefacts, not intentions
An access review that produced no record did not happen as far as an auditor is concerned. What gets sampled is the list reviewed, the person who approved it, the date, and the tickets showing what was removed. Revocations with no corresponding removal evidence are treated as open findings.
Where frameworks require IAM
| Framework | What it expects |
|---|---|
| SOC 2 | Logical access provisioning, modification and removal, with periodic review evidenced across the observation window |
| ISO 27001 | Annex A controls covering identity, authentication information, access rights and privileged access |
| RBI IT Governance Directions | Role-based access, segregation of duties, and periodic recertification for regulated entities |
| SEBI CSCRF | Least privilege, privileged access controls and access logging for market intermediaries |
| DPDP Act | Reasonable security safeguards, with access restriction to personal data a core expectation |
| PCI DSS | Unique identifiers per user, no shared credentials, and multi-factor authentication into the cardholder environment |
None of them prescribe a product. All of them ask the same three questions: who had access, why, and can you prove you checked.
How Osto runs IAM
Osto handles identity as part of the platform rather than as a bolt-on, which matters because access control only works when it reaches everything. Identity governs the endpoint, the cloud console, internal applications reached through ZTNA, and the web and API layer, so one directory decision propagates everywhere instead of stopping at whatever the SSO vendor happens to integrate with.
MFA is enforced at the access gate rather than left to each application. Sign-ins, privilege changes and failed attempts land in the same SIEM as endpoint and cloud events, so an unusual login followed by a new access key reads as one incident rather than two unrelated log lines. Review cycles and revocations produce evidence automatically, mapped to SOC 2, ISO 27001 and Indian sectoral frameworks from a single control set.
Platform walkthrough
One directory, every surface
Osto ties identity to endpoint, cloud, applications and the network in one platform, so access reviews are real and revocation actually reaches everywhere. One owner, one dashboard.
Book a demoMFA enforced at the gate · Access evidence mapped automatically · One platform, everything
Frequently asked questions
What is IAM?
Identity and access management: the discipline of controlling who has an account, what each account can reach, and how that access is reviewed and removed. It spans provisioning, authentication, authorisation, recertification and revocation across every system holding company data.
What is the difference between authentication and authorisation?
Authentication proves the identity is genuine. Authorisation decides what that identity is permitted to do once inside. A valid login with excessive permissions is an authorisation failure, not an authentication one, and it is the more common of the two.
Is single sign-on the same as IAM?
No. Single sign-on is one component. IAM also covers the directory itself, role design, privileged access, periodic review and revocation. SSO without scheduled access reviews still accumulates entitlements nobody can justify.
How often should access reviews run?
At least quarterly for privileged and production access, and at least annually for everything else, plus an immediate review whenever someone changes role or leaves. Each cycle should produce a record showing what was reviewed, by whom, and what was removed.
Does IAM cover service accounts?
It should, and this is where most programmes are weakest. Machine identities, API keys and CI/CD credentials need a named owner, a rotation schedule and the same review cycle as human accounts. Auditors increasingly sample them specifically.