Who should own approval and revocation for external privileged sessions?

Why This Matters for Security Teams

External privileged session are not a vendor convenience issue; they are a control-boundary issue. If a third party can approve or extend its own access, the organisation loses separation of duties, weakens auditability, and makes incident containment slower. That is especially dangerous for OWASP Non-Human Identity Top 10 class risks, where privileged access is often long-lived, overbroad, or poorly tracked.

NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks notes that 92% of organisations expose NHIs to third parties, which makes external access governance a routine attack surface rather than an edge case. The practical lesson is that approval and revocation must remain inside the organisation’s accountable domain, even when the session is initiated by a vendor or service partner.

Security teams often get this wrong by treating “vendor-managed” as an acceptable operating model for privileged access. In practice, many teams discover the weakness only after a stalled offboarding, an expired contract, or a disputed change has already created an access gap.

How It Works in Practice

The cleanest pattern is simple: the vendor requests access, but the organisation approves, scopes, monitors, and revokes it. That ownership usually sits with IAM, PAM, or security operations, with business system owners contributing approval context but not administrative control. Current guidance suggests using a workflow where access is time-bound, task-bound, and recorded in an immutable audit trail.

For external privileged sessions, the approval path should answer four questions at request time: who is requesting, what asset is being accessed, why access is needed, and how long the session should last. Revocation should be equally deterministic. When the task ends, the ticket closes, the session expires, and the credential or token is invalidated without relying on the vendor to self-report completion.

• Use PAM or session brokering to issue access only after internal approval.
• Enforce just-in-time access with short-lived credentials and fixed time-to-live.
• Log approval, session start, command activity, and revocation in the organisation’s SIEM or GRC record.
• Require internal review for exceptions, extensions, and emergency break-glass use.

This aligns with the governance emphasis in the Ultimate Guide to NHIs and with OWASP’s guidance on controlling lifecycle and privilege for non-human access. Where possible, pair approval with policy-as-code so that scope and expiry are enforced automatically rather than left to manual follow-up. These controls tend to break down in highly outsourced environments where the vendor also operates the ticketing system, because the approval trail and the revocation authority can become split across systems and owners.

Common Variations and Edge Cases

Tighter approval control often increases operational friction, requiring organisations to balance response speed against oversight. That tradeoff is real, especially for emergency maintenance windows, 24/7 support contracts, and regulated production environments.

There is no universal standard for every exception, but current guidance suggests that even emergency access should remain organisation-owned, with break-glass approvals, post-event review, and forced revocation after the incident window closes. Vendors may execute the work, but they should not control whether the session continues beyond the approved purpose.

In shared-service models, a business owner may validate the need while IAM or PAM enforces the session boundary. In managed-service arrangements, the contract should explicitly state that revocation authority remains with the customer, not the provider. This is where many programmes fail: the policy says the organisation owns access, but the tooling, help desk, or outsourced operations team still lets the vendor extend the session informally.

That distinction matters because privileged access is only trustworthy when the approval chain and the shutdown chain both remain inside the organisation’s control boundary.

Related resources from NHI Mgmt Group

• Who should own approval and revocation for agent sessions?
• Who should own secrets governance when workloads span GCP and external systems?
• Who should own access revocation when a supplier contract or project ends?
• Who should own escalation when a privileged account hits a threat indicator?