How should security teams govern access requests for both users and service accounts?

Security teams should use the same governance model for both, but apply it to the correct actor type. Requests need an owner, a justified business purpose, approval boundaries, and a revocation path. For service accounts, that also means tying the grant to rotation, expiry, and lifecycle offboarding rather than leaving the credential active after the original use case ends.

Why This Matters for Security Teams

Access governance breaks down when teams treat service accounts as a special exception instead of another governed actor type. Human requests are usually reviewed through HR, manager, and role context, while non-human access often starts as a workaround for deployment, integration, or automation. That gap is where standing privilege, hidden owners, and forgotten credentials accumulate. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, reinforcing why request governance must cover both actor types consistently.

The practical issue is not whether a request is human or machine generated, but whether it can be tied to a clear owner, a documented purpose, and a revocation event. That aligns with the NIST Cybersecurity Framework 2.0 emphasis on access control and lifecycle discipline, and with NHIMG guidance in the Ultimate Guide to NHIs on lifecycle visibility and offboarding. In practice, many security teams encounter persistent service-account access only after a review, incident, or application decommissioning has already exposed the gap.

How It Works in Practice

The strongest pattern is to use one approval workflow, then vary the policy checks by actor type. For users, that usually means confirming job function, manager approval, and least-privilege scope. For service accounts, the same workflow should require an application owner, a named business service, a technical justification, and an expiry date that matches the task or system need. The OWASP Non-Human Identity Top 10 is clear that unmanaged credentials and overprivileged service identities create recurring exposure, so approvals should not be treated as a one-time ticket closure.

Operationally, the request record should carry four controls:

• Owner identity: a human accountable for the request and a separate technical owner for the workload.
• Purpose binding: the exact system, integration, or workflow the access supports.
• Time limit: a defined review or expiry date, especially for elevated permissions.
• Revocation path: a documented trigger for deprovisioning, rotation, or offboarding.

For service accounts, that revocation path must connect to secrets rotation and lifecycle automation. If a credential cannot be revoked cleanly, the request process is incomplete. NHIMG’s Lifecycle Processes for Managing NHIs section stresses that access approval and offboarding need to be linked, not treated as separate operations. These controls tend to break down in legacy systems where one credential is reused across multiple applications because no single owner can safely attest to its full blast radius.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, so organisations have to balance speed against the risk of invisible standing access. Current guidance suggests that this tradeoff is acceptable only when exceptions are formally time-bound and monitored, not when teams create permanent blanket access for “automation.” That is especially important for shared service accounts, break-glass identities, and third-party integrations, where the requester may not be the same person who later operates or retires the credential.

One recurring edge case is platform-owned access. A deployment pipeline, backup job, or monitoring tool may need access that outlives a single engineer, but that does not justify open-ended credentials. Instead, approval should attach to the platform service, not the individual who created it, and the access review should verify that rotation, logging, and revocation are still functioning. NHIMG’s Regulatory and Audit Perspectives section is useful here because auditors increasingly expect a defensible chain from request to owner to offboarding. In organisations with high change velocity, the model works best when reviews are automated, exceptions are short-lived, and access is revalidated whenever the workload changes materially.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities alongside human accounts?
• How should security teams govern API keys used for generative AI access?