IaaS, in this article, refers to Identity as a Service. It is a shorthand label for a service-based approach to identity management, where access and governance capabilities are delivered through a hosted or managed model. Practitioners should avoid confusing it with infrastructure terminology when discussing IAM strategy.
Expanded Definition
IaaS here means Identity as a Service, a service-based delivery model for identity capabilities such as authentication, directory functions, federation, lifecycle administration, and policy enforcement. It is not an infrastructure label in this glossary context, and that distinction matters because identity services are often consumed as a managed control plane rather than built and operated entirely in-house. The term is used most accurately when the organisation depends on a hosted identity platform to centralise access governance across employees, contractors, and, increasingly, non-human identities.
Definitions vary across vendors on how much of identity governance, privileged access, and directory management belongs inside the label, so the safest reading is functional rather than product-specific. A practical reference point is NIST SP 800-53 Rev 5 Security and Privacy Controls, which helps teams map identity-related responsibilities to explicit control outcomes instead of assuming a service package covers everything. The most common misapplication is treating IaaS as a complete IAM substitute, which occurs when teams assume the hosted service automatically covers governance, integration, and assurance requirements.
Examples and Use Cases
Implementing Identity as a Service rigorously often introduces dependency on an external control plane, requiring organisations to weigh agility and standardisation against vendor dependency and integration complexity.
- A mid-sized enterprise uses a hosted identity platform for single sign-on and lifecycle provisioning across SaaS applications, reducing manual joiner-mover-leaver effort.
- A security team uses the service to enforce conditional access policies and centralised MFA for workforce accounts, while keeping sensitive administrative functions under separate privilege controls.
- An organisation extends the platform to federate external partners, allowing controlled access without creating unmanaged local accounts.
- Identity governance teams integrate the service with HR and ticketing systems so access changes follow business events rather than ad hoc requests.
- Where non-human identities are present, the hosted model is used to standardise secrets rotation, service account visibility, and policy enforcement across environments.
Teams looking for a control-oriented lens can compare the service’s claimed capabilities against the control intent in NIST guidance rather than assuming feature names equal security outcomes.
Why It Matters for Security Teams
IaaS matters because identity is a control point, not just an administrative convenience. When identity capabilities are outsourced or centralised, the organisation still owns risk decisions around authentication strength, provisioning quality, auditability, and policy enforcement. If the term is misunderstood, teams may overestimate coverage, leave shadow accounts active, or miss gaps between the hosted identity platform and downstream systems. That becomes especially important where IAM overlaps with NHI governance, because service accounts, API keys, and automation identities often fail under the same lifecycle weaknesses as human accounts.
Security teams also need to distinguish service delivery from control responsibility. A provider may host the function, but the organisation still has to define access policy, monitor exceptions, and validate assurance. In practice, the biggest failure mode is assuming the platform’s default settings satisfy governance requirements without review. Organisations typically encounter identity sprawl, stale entitlements, or audit findings only after an access review or incident exposes the gap, at which point Identity as a Service becomes operationally unavoidable to correct.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Identity services support access control outcomes across users and systems. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management is central to hosted identity service responsibilities. |
| NIST SP 800-63 | AAL2 | Assurance levels inform how strongly identities should be authenticated. |
| OWASP Non-Human Identity Top 10 | NHI governance covers non-human identities managed through identity services. | |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero trust relies on continuous verification by identity-centric policy enforcement. |
Inventory service accounts, rotate secrets, and apply lifecycle controls to machine identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
