How should organisations verify identities in self-service onboarding?

Why This Matters for Security Teams

Self-service onboarding is often treated as a usability feature, but for identity security it is a trust decision. The core risk is not just account creation, but creating access that cannot be convincingly justified later. NHI Management Group notes that 97% of NHIs carry excessive privileges, and the same pattern appears when onboarding is approved too loosely or without durable evidence. That is why proofing, exception handling, and lifecycle review must be linked from the start.

Zero Trust thinking applies here: NIST SP 800-207 Zero Trust Architecture makes continuous verification more important than a one-time trust event. For NHI and machine-driven onboarding, the organisation should be able to show what was verified, at what assurance level, and who accepted residual risk. In practice, many security teams discover weak onboarding evidence only after a secrets exposure or privilege abuse has already occurred, rather than through intentional lifecycle review.

How It Works in Practice

Identity verification in self-service onboarding should be risk-based, not one-size-fits-all. The proofing method should match the sensitivity of the role, system, or secret being granted. Low-risk access may justify lightweight checks, while privileged workflows usually require stronger evidence, review, and step-up controls. For NHI onboarding, this often means separating simple registration from actual trust establishment.

Good practice is to record the evidence used to trust the identity and keep that record available for audit and later review. That record should show the proofing method, the assurance outcome, any exception, and the approver if policy required one. It should also connect to the lifecycle state of the identity so teams can revisit whether the access is still appropriate after onboarding.

A practical workflow usually includes:

• Step-up proofing for higher-risk access, rather than a universal form.
• Short-lived approval windows for exceptions, with automatic expiry.
• Evidence capture that ties the onboarding event to the identity record.
• Periodic reassessment during access review, offboarding, or rotation events.

This is especially important where onboarding feeds into secrets issuance or service account creation, because weak identity proofing can turn into long-lived compromise. The issue is visible across many NHI incidents, including cases such as the JetBrains GitHub plugin token exposure, where trust in the onboarding or integration path affects downstream risk. Current guidance suggests the onboarding record should be as reviewable as the access itself, not treated as disposable workflow noise. These controls tend to break down when onboarding is fully automated for high-privilege access because the system cannot validate context well enough before access is granted.

Common Variations and Edge Cases

Tighter proofing often increases onboarding friction and operational overhead, so organisations must balance assurance against user experience and time-to-access. That tradeoff is real, especially in developer platforms, partner onboarding, and machine-to-machine enrolment where delays can block delivery.

There is no universal standard for this yet. Best practice is evolving, but the pattern is clear: the more sensitive the access, the less acceptable it is to rely on self-asserted information alone. For high-risk onboarding, organisations often add manager approval, identity evidence checks, or federated trust from a stronger upstream provider. For lower-risk NHI use cases, automation may be acceptable if the proofing basis is still logged and the credential is scoped tightly.

Two common edge cases need special handling. First, delegated onboarding can create unclear ownership if the approver is not tied to the identity lifecycle. Second, bulk onboarding can hide poor evidence quality because the workflow is fast but shallow. The underlying control should still answer the same question: why was this identity trusted, and how will that trust be revalidated?

That is where governance matters most. When self-service onboarding is used for identities that can later access secrets, deploy code, or call APIs, the initial proofing decision must remain visible across the full lifecycle, not just at the point of registration.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• What should organisations verify before relying on self-service identity features?
• How should teams govern self-service data access without creating shadow analytics?
• How should organisations verify whether media is authentic before they act on it?