Accountability sits with the organisation that designed the control boundary. Identity teams can disable the account, but the application team still owns session enforcement inside the product. If the app cannot consume revocation signals or invalidate sessions on demand, termination remains incomplete until the token expires, which is a governance and control failure.
Why This Matters for Security Teams
When a terminated employee can still use an already-issued session, the problem is not just identity proof at login. It is the mismatch between authentication and ongoing access control. The organisation may have completed HR offboarding and disabled the account, yet the application still trusts a live token, cookie, or session until expiry. That creates a control gap that belongs to the system owner as much as the IAM team.
This issue is common in environments where applications do not consume revocation events, do not re-check policy after login, or rely on long-lived sessions for convenience. The OWASP Non-Human Identity Top 10 treats weak lifecycle and session handling as a real security failure, not a theoretical one. NHI Mgmt Group also notes that only 20% of organisations have formal processes for offboarding and revoking API keys in its Ultimate Guide to NHIs, which is a useful signal of how often revocation is incomplete in practice. In practice, many security teams encounter this only after offboarding has already happened and the account is still able to act inside the application.
How It Works in Practice
Accountability should be assigned across two layers. The identity team owns account disablement, directory lifecycle, and upstream revocation signals. The application team owns enforcement inside the product: session invalidation, token introspection, logout propagation, and re-authentication when risk changes. If the app only checks identity at login, then termination is not actually enforced at the point where access continues.
The operational fix is to move from one-time authentication to continuous enforcement. That usually means:
- shortening token and session time-to-live so stolen or stale access expires faster
- supporting server-side session revocation, not just client-side logout
- consuming identity provider deprovisioning or revocation events in near real time
- using policy checks at request time for sensitive actions, not only at login
- logging session use after termination so security and audit teams can prove whether revocation worked
For identity governance and access design, NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because it maps well to access enforcement, account management, and session control expectations. The Lifecycle Processes for Managing NHIs section also shows why lifecycle events must be treated as operational controls, not administrative cleanup. Where applications support it, the best practice is to make session validity conditional on the current identity state rather than on the state at login.
These controls tend to break down in legacy applications, vendor-managed SaaS products, and systems with no revocation API because the application cannot be told that the user is no longer authorised.
Common Variations and Edge Cases
Tighter session enforcement often increases operational overhead, requiring organisations to balance user convenience against faster termination risk reduction. That tradeoff is real, especially for high-availability business applications and mobile clients that expect long-lived logins.
There is no universal standard for this yet, but current guidance suggests that applications serving sensitive data should not rely on login-time checks alone. Some systems can use central identity providers with continuous token introspection, while others need explicit session stores and back-channel logout. In regulated environments, this becomes part of the control boundary, not an optional enhancement. The Top 10 NHI Issues is a practical reminder that stale access is often a lifecycle failure, not an authentication failure.
Edge cases matter. Offline-capable apps may not be able to verify revocation on every request. Third-party applications may accept tokens until expiry even after directory disablement. Shared accounts can make accountability harder because the real user cannot be tied to the session cleanly. In those environments, the app owner still owns the design decision, but the organisation may need compensating controls such as shorter TTLs, step-up authentication, and stronger audit trails. The right answer is not to blame a single team, but to close the boundary where access actually persists.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Session persistence after offboarding is a lifecycle and revocation gap. |
| NIST CSF 2.0 | PR.AC-4 | Access rights must be managed and removed when employment ends. |
| NIST SP 800-63 | Identity assurance alone does not solve ongoing session control. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous authorization, not login-only checks. | |
| NIST AI RMF | Governance must define accountability for access decisions across system boundaries. |
Use strong authentication plus reauthentication and session binding for sensitive access.
Related resources from NHI Mgmt Group
- Who is accountable when access is blocked because a device fails posture checks?
- Who is accountable when a non-human identity keeps unnecessary Azure access?
- Who is accountable when biometric identity checks are used for age or access decisions?
- How should security teams run access reviews for non-human identities?
