Joiner Process

Expanded Definition

The joiner process is the controlled start of identity lifecycle management: it creates a new identity record and assigns the first set of entitlements, approvals, and traceable ownership. In NHI environments, the same logic applies to service accounts, API keys, workload identities, and agent credentials, not only to employees. The key distinction is that joiner is not a ticket to “create access” broadly; it is the point where access must be justified, minimised, and recorded so it can later be reviewed, rotated, or removed.

Definitions vary across vendors on whether joiner belongs to IAM, IGA, or HR-driven onboarding, but the operational goal is consistent: establish access with a verified source of truth and a clear approval trail. That aligns with the access governance expectations reflected in NIST Cybersecurity Framework 2.0 and with lifecycle-based NHI controls described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. The most common misapplication is treating joiner as a simple account-creation event, which occurs when teams provision default or preapproved access before role validation and ownership checks are complete.

Examples and Use Cases

Implementing joiner rigorously often introduces slight onboarding friction, requiring organisations to weigh speed of activation against the cost of overprovisioning and later remediation.

• A new engineer starts and receives only the Git, CI/CD, and observability permissions tied to the approved role, not broad production access.
• A workload identity is created for a microservice, with the request linked to the deployment record and the owning team.
• An AI agent is onboarded with a scoped token, a named approver, and a documented tool boundary before it can execute actions.
• A third-party integration is issued credentials only after the vendor agreement, purpose, and expiry date are recorded in the identity system.

These patterns mirror the lifecycle discipline discussed in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the identity governance orientation of the NIST Cybersecurity Framework 2.0. In practice, joiner decisions should also reflect whether the credential will later be rotated, delegated, or federated, because the initial provisioning path affects every downstream control.

Why It Matters in NHI Security

Joiner quality determines whether identities enter the environment with clean ownership and bounded privilege or with inherited risk. In NHI security, weak joiner workflows are a major source of secret sprawl, excessive permissions, and orphaned access paths that are difficult to unwind later. NHIMG research shows that NHI Mgmt Group found 97% of NHIs carry excessive privileges, which makes poor initial provisioning a structural problem, not a clerical one. That risk compounds when credentials are created outside a governed lifecycle, because the joiner step becomes the root of future offboarding failure.

The practical security issue is not just who gets access, but whether that access can be audited, justified, and removed without guesswork. That is why the joiner process must connect to source-of-truth systems, approval evidence, entitlement catalogs, and clean deprovisioning controls. NHI teams should treat joiner as the first checkpoint in an end-to-end lifecycle, not as a one-time onboarding task. Organisations typically encounter the consequences only after a breach review or failed offboarding, at which point joiner governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when deprovisioning is not tied to the joiner-mover-leaver process?
• Why do NHI programmes need stronger process ownership than many human identity programmes?
• How should organisations govern API partner onboarding as a non-human identity process?
• How can security teams apply GRC maturity benchmarks without creating process bloat?