The act of disabling or removing access in the system that truly holds the account, rather than only recording a workflow closure. In practice, auditors care whether the entitlement changed at the source, because a closed ticket does not prove the account is gone.
What Source-System Revocation Means in Practice
Source-system revocation is the difference between closing a process record and changing the real entitlement state. It matters because the authoritative system, not the ticket, is where access actually lives.
When an account is disabled at the source, the decision propagates from the system of record for that identity or entitlement. When revocation is only logged in a workflow tool, the organisation may believe access is gone while the real account, token, role, or group membership still exists.
Why the Source of Revocation Matters
The key idea is authority. Every environment has one system that is treated as the source of truth for a given access relationship, such as an HR platform, IAM directory, SaaS admin console, cloud identity provider, or application-specific user store. Source-system revocation means changing the entitlement where it is actually enforced or synchronised, not just noting that a request was completed.
This distinction becomes important whenever access is federated or copied across systems. If deprovisioning stops at the service desk or workflow layer, downstream systems can retain active access even though the business believes the user has been removed. The control objective is therefore state change, not administrative closure.
What Auditors and Reviewers Look For
Reviewers usually test whether revocation can be evidenced in the authoritative system itself. They want to see the account disabled, the role removed, the credential expired, the group membership stripped, or the provisioning connector confirmed as having executed the change.
That is why source-system revocation is often discussed alongside lifecycle control and access governance. A closed request can support process traceability, but it does not by itself prove that the entitlement no longer grants access. The operational question is whether the source has been updated so that the account cannot continue to authenticate or authorise actions.
Common Failure Patterns
Source-system revocation fails when organisations confuse orchestration with enforcement. A ticket may move through approval states, yet the deprovisioning step never reaches the source system, a downstream application, or a synchronised identity store. Delays, connector errors, manual exceptions, and orphaned accounts are common reasons the real access state diverges from the workflow record.
It also fails when different systems are treated as equally authoritative without clear ownership. In that situation, one platform may show the user as closed while another still recognises the account as active. The result is stale access, weak audit evidence, and a false sense of completion.
Risk and Threat Considerations
Source-system revocation is a control point because stale entitlements can survive long after a departure, role change, or offboarding action is believed to be complete. That creates exposure for unauthorized access, privilege retention, and account reuse.
Failure mechanism: The workflow is closed before the authoritative system removes the entitlement, so the identity remains usable in one or more live systems.
Impact: Attackers, insiders, or unintended users may continue to access data or functions, and auditors may find that recorded process completion did not translate into actual access removal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Source-system revocation is a core account lifecycle control issue. |
| AC-6 — Least Privilege | Revocation prevents retained access from exceeding current business need. | |
| IA-5 — Authenticator Management | Revocation often requires expiring or invalidating authenticators, tokens, or keys at the source. | |
| Recommendation — Ensure account disabling and removal actions are executed in the authoritative system of record. Remove unneeded entitlements at the source so access stays limited to current duties. Invalidate credentials and authenticators in the source system when access is withdrawn. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Source-system revocation directly concerns removal and adjustment of access rights. |
| Recommendation — Review and revoke access rights in the system that actually grants them. | ||
| CIS Controls v8 | CIS-5 — Account Management | The term is fundamentally about ensuring accounts are disabled where they are governed. |
| Recommendation — Disable or remove accounts in the authoritative system, not only in the workflow tool. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity management, authentication and access authorizations are managed for authorized users, services and hardware | The subject is about ensuring access authorizations are actually changed, not merely recorded. |
| Recommendation — Verify access authorizations are updated in the source system that enforces them. | ||
Practitioner Guidance
Why practitioners should care: The control is only real when the source changes. Treat the authoritative system as the proof point for revocation, and use the workflow record as supporting evidence rather than the control itself.
What to watch for: Pay close attention to systems where entitlements are cached, synchronised asynchronously, or manually administered outside the main joiner-mover-leaver process. Those are the places where “closed” often means “not yet removed.”
Practitioner takeaway: If you cannot show the access state changed in the source system, you do not yet have strong revocation assurance.
Related resources from NHI Mgmt Group
- Why do identity programs lose coverage after onboarding a source system?
- Why do downstream data copies create more risk than the source system?
- What breaks when organisations treat a source of truth and a system of record as the same thing?
- When does using a single source control system for infrastructure automation create operational risk?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org