Should organisations use the same process for onboarding people and machine identities?

Why This Matters for Security Teams

Using one onboarding process for people and machine identities creates a governance blind spot. Human onboarding is built around employment status, training, approvals, and role fit. NHI onboarding is built around workload purpose, ownership, secrets, rotation, and revocation logic. When those are merged, automation credentials can inherit employee-style exceptions, while risk owners lose sight of where secrets live and how long they remain valid. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames identity as an operational control, not just a provisioning event.

The practical issue is scale and exposure. NHI Mgmt Group research shows NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts. That gap matters because machine identities are often created by pipelines, not service desks, and they may outlive the project that introduced them. The lifecycle thinking in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is the right model for these assets, not employee HR workflows.

In practice, many security teams only discover this mismatch after a stale API key or service account has already been used to move laterally.

How It Works in Practice

The cleanest operating model is to treat people and machines as different identity classes with different control paths. Human onboarding can stay tied to HR, role mapping, and access packages. NHI onboarding should begin with inventory, naming standards, owner assignment, secret issuance, intended workload, and a defined removal trigger. For machine identities, the question is not “who hired this account?” but “what workload owns it, what does it touch, and how is it retired?”

In mature environments, the initial request should be approved against business purpose, then translated into policy for the workload itself. That usually means RBAC for broad entitlement boundaries, plus finer-grained checks for runtime decisions. Current guidance suggests pairing this with JIT credential provisioning, short-lived secrets, and automated rotation so that access exists only as long as the task requires it. Where agents or autonomous workloads are involved, a static approval model is often too coarse. Instead, intent-based authorisation and workload identity can be evaluated at request time, using cryptographic identity and context rather than a one-time joiner workflow.

A practical pattern is to anchor the workflow in Zero Trust principles, then tie the workload to a measurable owner and revocation path. The JetBrains GitHub plugin token exposure case is a good reminder that developer tooling can leak machine secrets long before anyone notices. NIST’s NIST Cybersecurity Framework 2.0 and NIST Zero Trust thinking both support this separation because they emphasise continuous verification and controlled access paths.

• Use a separate NHI onboarding workflow with ownership, purpose, and expiry recorded at creation time.
• Issue short-lived secrets where possible, and revoke them automatically when the workload ends.
• Bind machine identities to workload identity primitives, not employee directories.
• Review machine access on rotation and offboarding events, not on HR events alone.

These controls tend to break down in CI/CD-heavy environments where identities are generated rapidly and shared across pipelines, because ownership and revocation become blurred.

Common Variations and Edge Cases

Tighter NHI controls often increase engineering overhead, so organisations have to balance deployment speed against revocation certainty. That tradeoff is real, especially for platform teams that manage hundreds of service accounts, API keys, and agent credentials. Best practice is evolving, but there is no universal standard yet for how much human approval should exist in highly automated environments.

One common exception is bootstrap access. New workloads may need a brief, controlled path to obtain their first credential or to register with a secrets manager. Another is emergency break-glass access, where a machine identity may need broader privileges for recovery. Those exceptions should be pre-approved, time-bound, and logged separately from ordinary onboarding. The goal is not to eliminate all flexibility, but to prevent machine credential from being treated like ordinary employee accounts.

For agentic systems, the distinction becomes sharper. A human may log in once and follow a stable role pattern. An Agent or AI Agent can chain tools, change tactics, and request new permissions during execution. That is why people onboarding and machine onboarding should remain separate even when the business owner is the same. The lifecycle may look similar on paper, but the control intent is different. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NIST’s identity guidance both support this separation as the safer default.

In environments with autonomous agents, shared service accounts, or vendor-managed integrations, the standard onboarding model breaks down because runtime behaviour changes faster than static approvals can keep up.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• Should organisations prioritize securing machine identities before expanding agentic AI use?
• When should organisations use just-in-time access for manufacturing identities?
• How should organisations govern machine identities across multiple regions?