Standing access turns a temporary business relationship into a persistent attack path. If contractor credentials, service accounts, or API tokens remain valid after offboarding, an attacker who compromises the supplier can still reach agency data or communications. The control failure is lifecycle governance, not just authentication. Organisations need ownership, expiry, and revocation to prevent inherited access from surviving the work it was created for.
Why This Matters for Security Teams
When contractors retain standing access after a project ends, the organisation has not just missed an administrative cleanup step. It has left an active trust relationship in place after the business need has expired. That creates unnecessary exposure across email, file systems, ticketing platforms, code repositories, cloud consoles, and machine-to-machine interfaces. In practice, the weak point is usually not a password policy, but the absence of a reliable offboarding process for people, service accounts, and tokens.
This matters because contractor access often spans multiple control owners. Procurement may end the contract, a project manager may close the work, and IT may never receive a precise revocation request. The result is shadow access that no one can fully account for. Current guidance in the NIST Cybersecurity Framework 2.0 emphasises governance, asset visibility, and access control as connected outcomes, which is exactly where this problem sits. If access is not tied to an owner and an expiry condition, it will persist by default.
For government contractors, the stakes are higher because inherited access can include sensitive communications, regulated records, or privileges in shared environments used across multiple programmes. The same issue applies to non-human identities such as shared service accounts and API tokens, which are often forgotten because they are not tied to a named user. In practice, many security teams encounter this only after a contract has ended and access is still functioning, rather than through intentional lifecycle review.
How It Works in Practice
Standing access breaks lifecycle governance in three places: creation, change, and termination. At creation, the organisation often grants broad access to help the contractor start work quickly. During the project, permissions expand as tasks change. At termination, the offboarding step is incomplete because the organisation cannot easily identify every account, token, key, role assignment, and delegated permission that was granted on the contractor’s behalf.
Effective control depends on treating access as time-bound and attributable. That means each contractor relationship needs an owner, a documented purpose, a clear expiry date, and a revocation path that covers both human and non-human identities. For cloud and software environments, the same revocation logic must extend to IAM roles, service principals, CI/CD secrets, SSH keys, OAuth grants, and machine credentials. Where shared systems are used, teams should prefer separable entitlements so that one project’s access can be removed without disrupting others.
A practical implementation usually includes the following:
- Link every contractor account to a contract, project, or ticket with a defined end date.
- Review all active privileges before extension, not after renewal.
- Revoke human access, then verify removal of tokens, keys, and delegated grants.
- Log the offboarding action and retain evidence for audit and incident response.
- Apply periodic recertification for dormant but still-valid access paths.
The NIST security control family in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this approach through account management, access enforcement, and auditability expectations. The related OWASP Non-Human Identity Top 10 is especially relevant where contractors are issued API keys, automation tokens, or service identities that outlive the engagement. These controls tend to break down when access is provisioned through ad hoc exceptions in fast-moving delivery environments because no system owns the full revocation chain.
Common Variations and Edge Cases
Tighter access control often increases operational overhead, requiring organisations to balance delivery speed against revocation assurance. That tradeoff is real in emergency support, multi-agency programmes, and long-running maintenance contracts where access changes frequently. Best practice is evolving, but there is no universal standard for this yet on how much temporary privilege is acceptable before it must be formally recertified.
Some environments also create edge cases that complicate offboarding. A contractor may leave the organisation but remain embedded in a shared vendor-managed platform. A service account may be used by both a contractor and an internal automation job. A federated identity may still authenticate successfully even after local HR records show the engagement as closed. In these cases, the control objective is not simply “disable the user,” but “remove every path that still authorises the same work.”
Government programmes that use privileged break-glass access, shared test tenants, or external support channels should add compensating controls such as short-lived credentials, explicit re-approval for extensions, and periodic discovery of orphaned accounts. Where the question involves non-human identities, the governance model should treat secrets and tokens as first-class assets rather than technical leftovers. That is the practical lesson: if access cannot be traced to a living business need, it is already a liability rather than a capability.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Standing access is an access control and governance failure across the identity lifecycle. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management covers provisioning, review, and timely deactivation of contractor access. |
| OWASP Non-Human Identity Top 10 | Contractor-issued service accounts and tokens are non-human identities that often survive offboarding. |
Tie every contractor entitlement to an owner, expiry date, and revocation check before project closeout.
Related resources from NHI Mgmt Group
- What breaks when collaboration platforms keep standing access for contractors and suppliers?
- What breaks when movers keep inherited access after a role change?
- Who is accountable when revoked sessions keep working after access should end?
- What breaks when organisations keep standing privilege for high-risk admin access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
