Who should be accountable for revoking temporary group access when a project ends?

Why This Matters for Security Teams

Temporary group access is supposed to be a narrow exception, but in practice it often becomes a lingering entitlement after the work ends. That matters because the risk is not the approval event alone. It is the gap between approval and cleanup, where stale access can be reused, inherited, or forgotten. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which reinforces why lifecycle ownership has to be explicit, not implied in a ticket queue.

The accountability question is really a control design question. Security can define the guardrails, and approvers can validate the request, but the project owner is the person closest to the business need and the end date. That is consistent with lifecycle guidance in the NHI Lifecycle Management Guide and the broader emphasis on offboarding discipline in the Ultimate Guide to NHIs. When temporary access is treated as “done” at approval time, organisations often discover the residual access only during an incident review or quarterly audit.

Current guidance suggests accountability should follow the work, not the approval record. In practice, many security teams encounter stale temporary access only after the project has already closed and the business owner has moved on.

How It Works in Practice

The cleanest operating model assigns the project owner or designated project leader three responsibilities: define the business need, confirm the expiry condition, and verify cleanup when the work concludes. Security should provide the mechanism, such as time-bound group membership, workflow approval, and automated expiration. The control objective is to make access self-ending whenever possible, with human review reserved for exceptions. That aligns with NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially access enforcement and least-privilege lifecycle expectations, and with the OWASP Non-Human Identity Top 10 emphasis on credential and access governance.

Operationally, strong teams separate four duties:

• Business owner: states the need, duration, and closure criteria.
• Approver: validates the request against policy and risk.
• Security or IAM team: implements time-bound access and logs it.
• System owner: monitors whether the group or entitlement still exists after the end date.

Where possible, use automatic expiry for group membership, scheduled review checkpoints, and removal notifications to the owner before the deadline. If the project is extended, the owner should reauthorize the access rather than letting it roll forward silently. The NHI Mgmt Group 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both reinforce the same lesson: unmanaged leftovers are how temporary access turns into standing access. These controls tend to break down in matrixed organisations where project ownership is unclear because no single person feels responsible for the final revocation.

Common Variations and Edge Cases

Tighter cleanup rules often increase coordination overhead, requiring organisations to balance assurance against project speed. That tradeoff matters most when projects are short-lived, cross-functional, or dependent on external partners. In those cases, guidance suggests the business owner still remains accountable, but the execution may be shared with a service owner, vendor manager, or PMO if the project owner is unavailable. The key is that accountability stays attached to the business outcome, not to an approval inbox.

There is no universal standard for every organisational structure, but best practice is evolving toward explicit expiry ownership, especially for access that supports automation, CI/CD, or service accounts. Temporary group access should be treated like any other time-bounded privilege: named owner, end date, review checkpoint, and documented removal. If a group supports multiple projects, the owner must track which members belong to which workstream so that one closeout does not silently remove legitimate access for another.

For higher-risk environments, combine ownership with compensating controls such as PAM, just-in-time access, and periodic attestation. The important point is that a “temporary” group is not safe because it was approved once. It is safe only when the project owner can prove the access ended as planned.

Related resources from NHI Mgmt Group

• How should security teams manage temporary project access without creating access sprawl?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when subcontractor access remains open after a project ends?
• Who is accountable when temporary workers retain access after the season ends?