Usually not. Human users, service accounts and agents differ in ownership, review cadence and offboarding requirements, so a single workflow often hides the controls that matter most for each identity type.
Why a Single Workflow Breaks Down
Human users, service accounts and autonomous agents are not just different account labels. They differ in who owns them, how changes are approved, how access is reviewed, and how they are removed or disabled. A workflow that treats them the same tends to hide the controls that matter most, especially for offboarding, exception handling and accountability.
The practical problem is not that one process is impossible, but that one set of steps usually produces the wrong evidence for at least one identity type. For humans, you often need manager approval, role-based review and joiner-mover-leaver handling. For non-human identities, you usually need technical ownership, dependency checks, credential rotation or revocation, and a way to confirm that automation will not break when access is changed.
That difference matters because the access request is only one part of the control. The real control objective is to ensure the identity can be traced, reviewed and removed in a way that fits how it actually operates. If the workflow is too generic, teams end up approving access without confirming ownership or revocation impact.
For a broader identity model, the distinction between people and machines is central enough that separate treatment is often justified. NHIMG’s Human vs Non-Human Identity explains why ownership, lifecycle and governance diverge, while IAM and IGA Basics shows how provisioning and access review disciplines differ across workforce and machine access.
Where Unified Workflows Create Blind Spots
A single workflow commonly obscures one of three things: ownership, review cadence, or offboarding. Human access is usually tied to a person, a manager and an employment event. Non-human access is tied to a system, integration, workload or agent, which means the real owner may be a platform team, an application team or a service integrator rather than a line manager.
Review cadence also changes. Human access is often recertified on a periodic or event-driven basis. Non-human access often needs tighter technical review around secrets, scopes, tokens, certificate expiry, environment boundaries and dependency maps. If those details are compressed into a single ticket or approval form, the process can pass without testing the part most likely to fail.
Offboarding is the sharpest difference. A human leaver usually means account disablement and entitlement removal. A service account or agent may need token revocation, key rotation, certificate renewal failure prevention, downstream dependency checks and sometimes a controlled decommissioning sequence. If the workflow does not distinguish these states, organisations can leave dormant machine access in place long after the business owner thinks it is gone.
NHIMG’s Service Account Security Guide and NHI Ownership and Accountability Guide are useful references when the issue is ownership and lifecycle, while Guide to NHI Rotation Challenges covers the operational reality of rotating credentials without breaking dependent systems.
What Good Looks Like in Practice
The better pattern is usually one intake, then different routing by identity type. The request form can be shared, but the approval path, control checks and closure steps should branch based on whether the subject is a human, service account, workload or agent. That keeps governance consistent without pretending the risk is identical.
Good practice is to require the workflow to ask a few identity-specific questions: Who owns this identity? What system or business process depends on it? What proof shows the access is still needed? What is the revocation plan if the identity is no longer required? Those questions matter more than the cosmetic simplicity of a single approval chain.
At scale, this design is usually easier to govern than a one-size-fits-all model. It lets teams standardise the front door while preserving the control differences that prevent orphaned access, excessive privilege and failed offboarding. It also makes audit evidence stronger because the organisation can show that it used different control logic where the risk profile differed.
That is why NHIMG’s Access Reviews and Certification Guide is relevant here, along with Top 10 NHI Issues for the failure patterns that show up when ownership, visibility and offboarding are not handled separately.
Risk and Threat Considerations
When organisations force human and non-human access through the same workflow, the most common risk is hidden privilege. Approvers may sign off on a request without realising they are authorising a reusable secret, a long-lived token or a machine account with broad downstream reach.
Failure mechanism: The workflow collects the same fields for different identity types, so the review never forces the controls that matter for machine access, such as ownership verification, secret lifecycle checks or dependency validation. That creates a path for dormant, overprivileged or orphaned access to persist.
Impact: Access can remain active after business need has ended, secrets can outlive their intended use, and an abused machine identity can provide a stronger persistence or lateral-movement path than a normal user account.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of credentials and secrets used by humans and machines. |
| AC-2 — Account Management | Supports provisioning, review and removal of user and system accounts. | |
| IA-9 — Service Identification and Authentication | Directly addresses non-human services and workloads authenticating to each other. | |
| Recommendation — Manage secret issuance, rotation, storage and revocation separately by identity type. Use distinct account governance steps for people, service accounts and agents. Apply service-authentication controls for non-human access instead of human-style approvals. | ||
| CIS Controls v8 | CIS-5 — Account Management | Addresses account lifecycle, least privilege and removal of unused access. |
| Recommendation — Separate account lifecycle checks for workforce and non-human identities. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Non-human access needs explicit retirement and revocation paths. |
| NHI-05 — Overprivileged NHI | Unified workflows often miss excessive permissions on service accounts and agents. | |
| NHI-07 — Long-Lived Secrets | Shared workflows can normalise secrets that outlive their business purpose. | |
| Recommendation — Build offboarding steps that revoke machine secrets, tokens and certificates. Review non-human access against least privilege before approval. Enforce expiry and rotation for non-human secrets rather than indefinite reuse. | ||
Practitioner Guidance
What to prioritise: Keep one front door if you want, but do not keep one approval logic. Separate the workflow by identity class at the control points that change risk, especially ownership, review cadence and revocation.
What to verify: Before you trust a unified workflow, confirm that it captures technical ownership for non-human identities, not just a human approver. If the process cannot show who will rotate, revoke or retire the access, it is not complete.
Common mistake: Treating “same request form” as proof that “same workflow” is safe. Shared intake is fine; shared control logic is where organisations usually lose visibility.
Practitioner takeaway: Standardise the intake, not the governance decision. The more an identity can act without a person present, the more the workflow must force explicit ownership and lifecycle controls.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- What breaks when organisations use one IAM model for humans and non-human identities?
- What happens when organisations try to govern human users and non-human identities with the same legacy workflow?