User deprovisioning removes the person’s ability to authenticate as a user, while secret revocation invalidates the machine credentials that may still exist in applications, scripts, or cloud services. Both are needed because a disabled account does not automatically kill the access paths created during work.
How user deprovisioning and secret revocation differ in practice
user deprovisioning and secret revocation solve different parts of the same offboarding problem. Deprovisioning removes a person’s right to sign in as that user, while revocation kills the credentials that applications, scripts, and cloud services may still hold. The difference matters because user access can end cleanly while tokens, keys, and certificates continue to authenticate elsewhere.
Deprovisioning is about the human account and the access path attached to it. In a mature joiner-mover-leaver process, it removes directory access, SSO access, and any linked entitlements that were granted to the individual. That is the right control when the question is, “Can this person still authenticate as themselves?”
Revocation is about the secret, not the person. A secret may be embedded in automation, a CI/CD job, a serverless function, a cloud integration, or a legacy script. The right question there is, “Does this token, key, or certificate still work anywhere?” A revoked secret can block machine-to-machine access even when the user account that created it has already been disabled.
Why the gap exists between account removal and access removal
The gap exists because modern systems rarely use only interactive human login. A person can leave, but the access they set up may survive in service accounts, API clients, deployment pipelines, or application configs. That is why Joiner-Mover-Leaver (JML) Guide treats offboarding as both an identity event and an access cleanup event, not just a directory action.
In operational terms, deprovisioning changes who may log in; revocation changes what still works unattended. A disabled account does not necessarily invalidate OAuth tokens, API keys, SSH keys, or signing keys already distributed to systems. If those materials are long-lived or copied into multiple places, the blast radius can outlast the user relationship that introduced them.
This is why lifecycle management must include discovery of where credentials live, not only where users exist. The distinction is also visible in NHI Lifecycle Management Guide, which pairs provisioning and offboarding with rotation, visibility, and decommissioning of credentials that persist beyond a person’s account.
What to do when the credential survives the user
The practical control point is the asset that still has authority. If the access path is a user session, deprovision the account and terminate sessions. If the access path is a secret, revoke or rotate the secret at the source, then identify every application, job, or environment that depended on it. For offboarding, the correct order is often account closure first, then secret inventory and removal, then confirmation that dependent services have switched to a new credential.
For teams using automated provisioning, SCIM and Automated Provisioning Guide is useful because it shows where deprovisioning can be automated and where it cannot. SCIM may remove a user from a target app, but it does not by itself clean up hardcoded secrets, tokens in code, or keys in cloud services.
The same distinction applies to machine credentials embedded in systems. Guide to the Secret Sprawl Challenge is relevant here because secret sprawl is what makes revocation harder than deprovisioning: the secret may exist in multiple repositories, pipelines, and runtime environments long after the original owner has gone.
Risk and Threat Considerations
The main risk is assuming that disabling a person removes all access. In reality, the residual risk often sits in unattended credentials, especially long-lived keys and tokens that continue to authenticate after the user account is gone. That creates persistence for accidental exposure and, if compromised, a convenient reuse path for an attacker.
Failure mechanism: the human account is deactivated, but the dependent secret remains valid in one or more systems, allowing continued non-interactive access, lateral movement, or unauthorized automation.
Impact: an organisation can believe offboarding is complete while production services, cloud resources, or build pipelines still accept the old credential, extending exposure and delaying containment.
Framework Alignment
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding must remove lingering non-human access paths after user exit. |
| NHI-02 — Secret Leakage | Secrets can persist in apps and scripts after the user account is removed. | |
| NHI-07 — Long-Lived Secrets | Long-lived credentials are the core reason deprovisioning is not enough. | |
| Recommendation — Revoke all machine credentials and dependent access paths when an owner leaves. Locate exposed secrets and rotate them before attackers reuse them. Shorten secret lifetimes and replace static credentials with rotatable alternatives. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle management of authenticators, including revocation and rotation. |
| AC-2 — Account Management | User deprovisioning is an account-management requirement. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Machine credentials authenticate services and applications, not just people. | |
| Recommendation — Manage authenticators through issuance, rotation, and revocation. Remove or disable accounts promptly and verify associated access is removed. Apply stronger lifecycle controls to non-user authenticators and service credentials. | ||
Practitioner Guidance
What to verify: confirm that your offboarding checklist separates account closure from credential invalidation. The evidence you want is not just “user disabled,” but also token revocation, key rotation, session termination, and confirmation that no application still depends on the retired secret.
Decision rule: if the access path was ever copied outside the human account, treat revocation as a separate control, not a subtask of deprovisioning. If you cannot inventory where the secret is used, assume the account disablement is incomplete until the dependent systems are found and updated.
Practitioner takeaway: user deprovisioning removes the person; secret revocation removes the machine path they may have left behind. Mature offboarding treats both as mandatory, because either one on its own leaves a usable access path.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?