Join our Newsletter — 33% off our NHI Course
Home› FAQ› Authentication, Authorisation & Trust› How should teams verify candidates before credentials are…
Authentication, Authorisation & Trust

How should teams verify candidates before credentials are issued?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated November 5, 2026 Domain: Authentication, Authorisation & Trust

Teams should verify the person, the claimed identity data and the consistency of supporting evidence before access is granted, then issue credentials only after that check passes. Use liveness verification, document validation, reference or employment confirmation, and risk-based manual review for mismatches. The goal is to stop false identities, not just create an account quickly.

What teams need to verify before issuing credentials

Verification is about proving the candidate is the right person, not just matching a form to an inbox. Teams should confirm the claimed identity data, test that supporting evidence is consistent, and look for signs that the applicant is presenting a false or substituted identity before any credential is created. If the evidence does not line up, the safest outcome is to stop issuance.

The practical question is whether the organisation has enough assurance to bind a credential to a real claimant. That means checking the person, the documents or records behind the claim, and any discrepancies that suggest fraud, impersonation, or an error in the enrolment flow. A fast onboarding process is not a substitute for a credible verification decision.

How to use layered verification without slowing everything down

Effective verification usually combines several checks rather than relying on one signal. Liveness checks help reduce spoofing, document validation helps confirm identity evidence, and reference or employment confirmation helps reconcile the claim against an external source. Where the result is ambiguous, risk-based manual review is the control that keeps edge cases from being auto-approved.

This is where process design matters. Low-risk candidates may clear with a standard flow, while higher-risk populations, such as privileged staff or external users with broader access, should face tighter review thresholds. The important principle is that the verification depth should match the potential harm if the identity is false.

What usually goes wrong in candidate verification

Failures tend to happen when teams treat verification as a box-ticking exercise. A document can look valid while the person behind it is not who they claim to be, and a successful account creation workflow can hide weak evidence handling. The common pattern is overreliance on a single control, especially when speed, outsourcing, or volume pressure reduces scrutiny.

Another failure mode is inconsistency across sources. If the name, contact details, employment record, or supporting documents do not align, that mismatch is often the earliest warning sign. Teams should assume that identity fraud attempts will try to exploit weak review paths, exceptions, and manual override habits.

Risk and Threat Considerations

Weak candidate verification creates direct exposure to account fraud, impersonation, and unauthorised access. Once a false identity is credentialed, the problem shifts from onboarding quality to access abuse, and the organisation may only discover it after data access, privilege use, or downstream fraud has already occurred.

Failure mechanism: Attackers or fraudulent applicants exploit gaps in evidence validation, liveness testing, or exception handling to obtain a credential for an identity they do not legitimately control.

Impact: The organisation can grant access to a non-genuine user, creating fraud risk, audit failure, recovery cost, and potential exposure of systems or data that should never have been reachable.

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-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63Digital Identity GuidelinesDirectly governs identity proofing and verifier assurance before credential issuance.
Recommendation — Apply the identity proofing assurance model before issuing credentials and escalate uncertain cases for higher review.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationCredential issuance for a false claimant creates authentication weakness and account takeover risk.
NHI-05 — Overprivileged NHIIncorrectly issued identities often lead to excessive access during onboarding.
NHI-07 — Long-Lived SecretsIssued credentials need lifecycle limits because weak onboarding can persist as durable access.
Recommendation — Require stronger verification before binding credentials to an identity claim. Limit initial access and grant only the minimum needed until identity confidence is confirmed. Use short-lived credentials and rotation controls to reduce the blast radius of a bad issuance.
NIST SP 800-53 Rev 5IA-12 — Identity ProofingIdentity proofing is the core control for confirming a claimant before credential issuance.
IA-5 — Authenticator ManagementCredentials must be issued, protected and managed as controlled authenticators after verification.
IA-2 — Identification and Authentication (Organizational Users)Organisational user enrolment depends on reliable identity verification before authentication is enabled.
Recommendation — Perform formal identity proofing before granting credentials to a new claimant. Issue and manage authenticators only after the identity proofing decision succeeds. Verify the user first, then enable authentication only for approved identities.

Practitioner Guidance

What to verify: Treat identity proofing as a decision with evidence thresholds, not a checklist. The minimum test is whether the person, the claimed attributes, and the supporting evidence all agree strongly enough to justify issuance.

Decision rule: If the applicant fails liveness, produces inconsistent documentation, or cannot be reconciled through a trusted reference source, do not issue credentials until the discrepancy is resolved. If the risk profile is elevated, require manual review rather than pushing the case through a standard queue.

Practitioner takeaway: The safest verification programme is one that makes it easier to reject weak claims than to accelerate them, because credential issuance is the point where identity errors become operational access.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org