Remote access revocation should be owned jointly, but one team must be clearly accountable. The article shows the failure point is the handoff between physical security, IT, and networking teams. Organisations need a defined owner for termination workflows so access removal is triggered automatically, confirmed across systems, and not left open because responsibility is ambiguous.
Who should own the revocation step after a worker leaves?
Remote access revocation should not sit in one silo as a best-effort task. It needs a named owner for the termination workflow, with HR or the line manager triggering the event, IT or IAM executing the access removal, and networking or remote access platform owners confirming the cutover. Accountability matters most at the handoff, where delay and ambiguity usually create the exposure.
Why joint ownership still needs one accountable team
Joint ownership works only when one team is clearly accountable for closure. Termination touches physical access, logical access, VPNs, remote desktop gateways, privileged accounts, and third-party access, so the worker can look “offboarded” in one system while still retaining a live path elsewhere. That is why the operating model should define one control owner for the entire revocation process, not several teams that assume someone else finished it.
The practical test is simple: if a departed worker can still authenticate anywhere that reaches internal systems, the offboarding process is incomplete. In many organisations, the failure is not the revoke itself but the lack of a single workflow owner who can see the full path from termination notice to confirmed access removal across all relevant systems.
What the revocation workflow must actually control
A complete remote access revocation workflow should cover account disablement, session termination, token or certificate invalidation where used, removal from remote access groups, and closure of any break-glass or delegated access paths. It should also include confirmation that downstream systems received the change, because “disabled in one console” is not the same as “no longer able to connect.”
For remote access specifically, the owner should verify the controls that matter to the entry path the worker used most often. NIST Cybersecurity Framework 2.0 is useful here because it reinforces governed, repeatable protection and response processes, while NIST AI Risk Management Framework is not the relevant model for this problem. The operational issue is access closure, not model risk. Where remote access relies on strong identity controls, NIST SP 800-207 Zero Trust Architecture supports the expectation that access is continuously verified and tightly bounded rather than assumed to remain safe after employment ends.
What fails when ownership is vague
Vague ownership creates a gap between the event that ends employment and the systems that still trust the person. That gap is dangerous because remote access is often the fastest path back into the environment, especially where VPNs, remote desktop, privileged tooling, or vendor-style access are involved. A terminated worker with a still-valid credential, session, or remote access entitlement can continue to reach systems long after the organisation believes the relationship is closed.
Remote Access Identity Guide is directly relevant because it treats remote access as an identity problem, not just a network problem. The same is true in practice for credentialed remote access failures such as SonicWall VPN Mass Breach via Stolen Credentials and Colonial Pipeline ransomware attack, which show how a single lingering access path can become the entry point for broader compromise.
Risk and Threat Considerations
When revocation ownership is unclear, the risk is not just an administrative delay. It is a live access window in which a former worker, or anyone who obtains their credentials, may still reach internal systems, remote desktops, or privileged admin paths. The longer the handoff remains ambiguous, the more likely stale access, shared credentials, or unclosed sessions will survive the departure.
Failure mechanism: Termination is processed in one system but not fully propagated to every remote access control point, so authentication or network reachability remains open after employment ends.
Impact: The organisation can suffer account misuse, unauthorized access, lateral movement, or delayed detection of a post-departure compromise, especially where remote access is the shortest path to sensitive systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-03 — Roles, Responsibilities, and Authorities | Offboarding needs one accountable owner for the revocation workflow. |
| PR.AA-05 — Least Privilege | Departed workers should lose all access paths, not retain dormant entitlements. | |
| Recommendation — Assign one accountable owner for remote access revocation and define handoff responsibilities. Revoke all unnecessary remote access and confirm access is removed everywhere. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Termination is an account lifecycle event requiring prompt disablement and review. |
| AC-17 — Remote Access | The question is specifically about controlling remote access after departure. | |
| Recommendation — Disable or remove accounts promptly when employment ends and verify propagation. Terminate remote access sessions and enforce revocation at each remote entry point. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be removed when employment ends or changes. |
| Recommendation — Remove access rights as part of a documented joiner-mover-leaver process. | ||
Practitioner Guidance
What to prioritise: Assign one accountable owner for the offboarding workflow, then make every other team a participant in execution rather than a co-owner of the outcome. The owner should be able to prove that remote access was removed everywhere the worker could reach, not just in the HR-linked identity store.
What to verify: Confirm that the revocation process closes the actual entry path used by the worker, including VPN, remote desktop, privileged access, certificates or tokens, and any lingering group membership. Privileged Session Management Guide is especially useful where administrative access must be monitored, recorded, or forcibly ended as part of offboarding.
Practitioner takeaway: Ownership should follow the control boundary, but accountability should sit with one team that can prove remote access is gone, because “someone else handled it” is exactly how stale access survives termination.
Related resources from NHI Mgmt Group
- Who should own revocation when an employee leaves and AI tools still have access?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- When do NHI access reviews create more value than a one-time cleanup?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
