The active attribute is a SCIM user field that indicates administrative status, not the full security state of a person. When set to false, it usually means the identity provider has marked the account inactive. Applications still need separate controls to revoke live access and prevent continued use of issued credentials.
Expanded Definition
In SCIM, NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the broader access-control context, but the active attribute itself is narrower: it is an administrative status flag that indicates whether an account is currently marked usable in the directory or provisioning source. It does not, by itself, prove that sessions are ended, refresh tokens are invalidated, API keys are revoked, or downstream entitlements have been removed.
That distinction matters in NHI governance because account state, credential state, and authorization state often move on different timelines. An identity provider can mark an account inactive while issued secrets, cached tokens, or directly embedded credentials continue to function elsewhere. In practice, the active attribute is one signal in a broader lifecycle process that should include offboarding, secret rotation, entitlement removal, and federation cleanup. The industry still varies in how strictly it interprets “inactive,” especially across SaaS apps and SCIM implementations, so the field should be treated as a provisioning control rather than a complete security shutdown.
The most common misapplication is assuming active false fully disables access, which occurs when teams equate directory status with revocation across all connected systems.
Examples and Use Cases
Implementing the active attribute rigorously often introduces lifecycle coordination overhead, requiring organisations to weigh faster deprovisioning against the operational cost of validating every downstream system.
- A contractor leaves, the IdP sets active to false, and the SaaS app must still revoke refresh tokens and session cookies to prevent continued use.
- A service account is marked inactive after a migration, but embedded API keys remain valid in CI/CD variables until rotation completes.
- An HR-driven offboarding workflow uses SCIM to deactivate a user while a separate PAM workflow removes standing administrative roles.
- A shared integration account is disabled in one tenant, yet a partner system retains cached authorization until the token expires or is explicitly revoked.
- An application syncs with Ultimate Guide to NHIs guidance to ensure deactivation triggers credential cleanup, not just directory updates.
In well-run environments, active is treated as the starting point for revocation, not the end state. That is especially important when identities are federated or machine-generated, because a false assumption about deactivation can leave privileged access intact across multiple systems.
Why It Matters in NHI Security
For NHI security, the active attribute is important because it often becomes the easiest visible signal of an identity’s status, even though it is not the full control plane. When security teams rely on it alone, they can miss the more dangerous problem: credentials and privileges that survive after a user, workload, or integration should have been removed. NHIMG research shows only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which means inactive status can create false confidence instead of real containment. The same risk appears in service-account governance, where lifecycle gaps and poor visibility combine to keep stale access alive long after it should disappear.
That is why active must be paired with access revocation, secret invalidation, and verification that downstream systems received the change. In a zero trust model, the state of a record in a directory is not enough to grant trust to a live session or a stored secret. Organisations typically encounter the real impact only after a compromised account, stale token, or forgotten integration is used for lateral movement, at which point the active attribute becomes operationally unavoidable to interpret correctly.
For broader lifecycle context, see Ultimate Guide to NHIs and use NIST SP 800-53 Rev 5 Security and Privacy Controls to map deprovisioning to formal control expectations.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle status flags are relevant where NHI deprovisioning and revocation must be verified. |
| NIST CSF 2.0 | PR.AC | Access control governance requires more than directory status to manage ongoing authorization. |
| NIST SP 800-63 | Digital identity assurance distinguishes identity status from authenticator validity. | |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes trust is continuously re-evaluated, not granted by account state alone. | |
| CSA MAESTRO | Agentic and automated entities need explicit lifecycle controls beyond a simple active flag. |
Treat active=false as a trigger to revoke tokens, keys, and entitlements across every connected system.
Related resources from NHI Mgmt Group
- What happened in the demo account left active in production scenario and what does it reveal?
- Why do Active Directory service accounts complicate zero trust programs?
- How should security teams govern Active Directory service accounts?
- What is the difference between direct access and effective access in Active Directory?
