The provisioning and deprovisioning of native accounts in AWS Identity Center through governance controls. This capability supports lifecycle management, ad hoc access requests, and account removal. It helps reduce gaps between identity governance decisions and the actual state of cloud access.
Expanded Definition
AWS IAM Identity Center provisioning is the governed creation, update, and removal of native access entries in AWS Identity Center so that identity decisions are reflected in cloud access without manual drift. In NHI management, this is less about simple onboarding and more about maintaining a controlled lifecycle for workforce and operational access.
The term is often applied alongside joiner, mover, and leaver workflows, but the operational boundary matters: provisioning governs when access is materialised, while entitlement governance decides whether the access should exist at all. Industry usage varies slightly across vendors, so teams should treat the term as an access execution layer, not a substitute for approval, role design, or periodic review. For control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls is the closest external baseline for access enforcement and account lifecycle discipline.
The most common misapplication is equating Identity Center provisioning with full identity governance, which occurs when access is created automatically but approval, review, and revocation remain fragmented elsewhere.
Examples and Use Cases
Implementing AWS IAM Identity Center provisioning rigorously often introduces workflow complexity, requiring organisations to weigh faster access delivery against tighter approval and deprovisioning control.
- A new engineer is assigned a role in an HR or ITSM workflow, and the approved entitlement is provisioned into AWS IAM Identity Center for time-bound access.
- A contractor’s project ends, and the same governance path removes the native account rather than leaving access to expire informally.
- A team lead requests elevated access for a maintenance window, and provisioning occurs only after the approval record is linked to the request.
- An access recertification campaign identifies stale assignments, and provisioning logic is used to reconcile the live state with the approved state.
- Identity lifecycle controls are tuned for cloud operations after patterns documented in the Ultimate Guide to NHIs show how unmanaged lifecycle gaps frequently persist in cloud environments.
For implementation patterns, AWS IAM Identity Center provisioning should be aligned with enterprise access review processes described in NIST SP 800-53 Rev 5 Security and Privacy Controls so that lifecycle actions remain auditable and repeatable.
Why It Matters in NHI Security
Provisioning matters because cloud access becomes dangerous when the approved identity state and the actual access state diverge. In NHI security, that divergence is a recurring source of excessive privilege, delayed offboarding, and orphaned access. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, a signal that lifecycle discipline is still weak across many access programs, even before cloud console access is considered.
When AWS IAM Identity Center provisioning is reliable, organisations can reduce standing access, shorten time to revoke, and enforce least privilege more consistently. When it is weak, access can persist after role changes, vendor completion, or internal transfers, creating an opening for misuse or lateral movement. The broader NHI problem is not theoretical: the 2024 Non-Human Identity Security Report found that 88.5% of organisations say their NHI practices lag behind or merely match their human IAM efforts, which helps explain why lifecycle execution is still immature.
Teams also benefit from the lifecycle framing in the NHI Lifecycle Management Guide, especially where provisioning must be tied to revocation and periodic review. Organisations typically encounter the need for disciplined provisioning only after a former user still has active cloud access, at which point the term becomes operationally unavoidable to address.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, 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-4 | Access permissions should be managed and enforced through lifecycle governance. |
| NIST SP 800-63 | Identity proofing and lifecycle assurance inform who may receive access. | |
| NIST Zero Trust (SP 800-207) | Zero trust depends on continuously validated access rather than durable standing entitlement. | |
| OWASP Non-Human Identity Top 10 | NHI-04 | Lifecycle drift and orphaned access are core non-human identity risks. |
| CSA MAESTRO | Agentic and cloud access controls require governed credential and entitlement lifecycle handling. |
Ensure access issuance is linked to verified identity and authoritative lifecycle events.
