By NHI Mgmt Group Editorial TeamBased on 1Kosmos: “Verifiable Credentials: A Deep Dive into Enhanced Identity Assurance” (March 21, 2025)

TL;DR: Verifiable credentials combine claims, source validation, document checks, biometrics, and liveness testing to strengthen identity assurance under NIST 800-63-3, according to 1Kosmos. The practical issue is not whether the model is stronger, but whether verification depth, fraud resistance, and false-positive handling are governed consistently across identity programmes.


At a glance

What this is: This is an identity assurance explainer showing how verifiable credentials combine claims, document checks, authoritative data sources, biometrics, and liveness tests to move verification beyond single-factor evidence.

Why it matters: It matters because IAM teams need assurance models that can withstand forged documents, deepfakes, and inconsistent verification depth when onboarding or re-verifying people across regulated and high-risk journeys.


Context

Verifiable credentials are a way to strengthen digital identity proofing by checking more than one source of evidence before assigning assurance level. In this article, the core issue is not authentication after login but how much confidence a programme can place in the identity proofing step itself.

That makes the topic relevant to human IAM, especially onboarding and identity proofing under NIST 800-63-3. The article argues that a single claim, document, or image is not enough on its own, because fraud, forged documents, and synthetic media can defeat shallow checks.


Key questions

Q: How should security teams set assurance levels for digital identity proofing?

A: Start by mapping each journey to the evidence needed for the risk involved, then require the same assurance level across channels that perform the same function. Identity proofing should be tied to policy, source quality, and error handling, not to whichever verification step is easiest to automate.

Q: Why do single-signal identity checks fail against modern fraud patterns?

A: Single-signal checks fail because they rely on one observation, such as a document image or a single device event. Attackers can bypass that with deepfakes, spoofing, SIM swaps, and automated fraud. Security teams need multiple, independent signals that support both possession and ownership, plus verification that continues across sessions instead of stopping at onboarding.

Q: How can organisations tell if identity proofing is too weak?

A: Look for repeated reliance on one-time checks, inconsistent approvals, and recovery actions that are accepted without strong context. If an attacker could answer the same questions or replay the same evidence across multiple attempts, the proofing model is too easy to stage. Stronger proofing should resist repetition and channel manipulation.

Q: Should organisations prioritise liveness checks or document verification first?

A: Neither should be treated as sufficient on its own. Liveness helps when the attacker uses a fake human presence, while document verification helps when the attacker starts with forged credentials or identity evidence. The better decision is to sequence both inside one risk-based flow, then add behaviour and device checks where fraud pressure is highest.


Technical breakdown

How claims become verified identity evidence

A claim is any statement a person makes about themselves, such as name, date of birth, or address. Verifiable credentials are built by testing those claims against trusted sources rather than treating one document or image as proof. In practice, that means the verification chain matters as much as the final score: each layer adds confidence only if it checks a different source of truth. Under NIST 800-63-3, the goal is to raise assurance by increasing evidence quality, not by multiplying weak checks.

Practical implication: design proofing workflows so every additional signal adds independent evidence, not just another copy of the same assertion.

Why document checks alone do not create assurance

Identity documents can support proofing, but they are not inherently trustworthy because they can be forged, stolen, or legitimately issued under false pretences. Cross-checking two documents can raise confidence, but that still leaves room for coordinated fraud if the source documents are compromised. The article’s staged model shows why identity assurance depends on provenance as well as appearance. A document that looks valid is only one input to a broader trust decision, not the decision itself.

Practical implication: treat document verification as a control input, then require authoritative source validation before assigning higher assurance.

What biometrics and liveness testing add to remote proofing

Biometrics and liveness checks help answer a different question from document validation: is the right person physically present right now? That distinction matters because deepfakes and replayed images can make static checks look convincing while the session itself is fraudulent. Dynamic prompts such as blinking or smiling add a challenge-response element that is harder to pre-record or automate. The control is strongest when the biometric, the device, and the live interaction are all tied back to the same proofing event.

Practical implication: require live challenge-response steps where remote proofing depends on presence, not just document authenticity.


NHI Mgmt Group analysis

Verifiable credentials are only as strong as the independence of the evidence behind them. A name, date of birth, document, and biometric sample do not automatically create high assurance if they all trace back to the same weak source. The programme decision is whether each signal materially reduces the chance of forged or stolen identity acceptance. That means practitioners should judge proofing depth by evidence independence, not by the number of checks performed.

IAL scoring is a governance commitment, not just a technical label. If one team treats dual-document checks as enough while another requires authoritative database validation and liveness testing, the organisation is effectively operating multiple assurance standards. That creates policy drift across onboarding channels, recovery flows, and high-risk transactions. Identity assurance only works when the same assurance level means the same evidentiary bar everywhere.

False positives and false negatives are part of the assurance model, not edge cases. The article correctly points out that genuine users can be rejected and fraudulent users can be accepted. The practical governance task is deciding what level of friction, review, and fallback process is acceptable at each assurance tier. Identity programmes that ignore error handling end up optimising for convenience at the expense of trust.

NIST 800-63-3 remains the right reference point because it forces programmes to connect evidence quality to assurance level. That linkage matters more than any single verification feature. The standard gives IAM teams a common language for comparing proofing depth across digital channels and vendors. Practitioners should use that language to align policy, not to outsource judgment to whichever check is easiest to automate.

Identity proofing is moving from static assertions to dynamic trust signals. Deepfakes, synthetic media, and replay attacks make the old assumption of visual sufficiency obsolete. The next control boundary is not just whether a credential looks valid, but whether the proofing event itself demonstrates freshness, presence, and source reliability. Teams that still rely on single-source verification are governing yesterday’s fraud model.

What this signals

Identity assurance is shifting from proof by possession to proof by evidence quality. Programmes that still treat a document scan as the main trust event will struggle to distinguish legitimate users from forged or synthetic identities. The practical change is to govern proofing as a chain of evidence, not a point-in-time check.

Verifiable credentials raise the bar only when the sources behind them are genuinely independent. If every signal is derived from the same weak assertion, the assurance score becomes decorative rather than decision-grade. IAM teams should align proofing policy to the evidence they can actually defend under audit and fraud review.


For practitioners

  • Standardise assurance tiers Map each onboarding and recovery flow to a defined assurance level so teams know exactly which evidence is required before granting access or completing identity proofing.
  • Require independent evidence sources Do not let one credential, one database check, or one biometric signal stand alone when the workflow claims higher assurance. Require multiple sources that answer different trust questions.
  • Add live presence checks Use liveness testing and challenge-response prompts for remote proofing where a static image or recorded video would be enough to bypass review.
  • Define false-positive handling Set escalation paths for good users who fail proofing and review paths for suspicious users who pass, so error handling is consistent across channels.

Key takeaways

  • Verifiable credentials are not a single control, but a layered identity proofing model that combines claims, documents, authoritative sources, biometrics, and liveness testing.
  • The central risk is inconsistent assurance depth, where different teams or channels treat different evidence standards as if they were equivalent.
  • IAM teams should govern proofing by evidence independence, assurance level, and error handling rather than by any one verification feature.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while GDPR defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63A — Enrollment and Identity ProofingThe article centres on identity proofing, assurance levels, and evidence quality.
SP 800-63B — AuthenticationBiometric and liveness controls support stronger authentication boundaries after proofing.
Recommendation — Align proofing flows to SP 800-63A assurance expectations before assigning access or trust. Use SP 800-63B to separate proofing evidence from later authentication requirements.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsIdentity assurance determines how confidently access permissions can be assigned.
Recommendation — Tie entitlement decisions to proofing confidence so weak verification does not lead to over-assignment.
GDPRArt.32 — Security of ProcessingRemote identity proofing and biometric handling can affect personal data protection controls.
Recommendation — Apply Art.32 safeguards when proofing processes collect or process biometric and identity data.

Key terms

  • Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.
  • Assurance Level: An assurance level is the degree of confidence an organisation has that an identity proofing or authentication outcome is accurate. Higher assurance usually means stronger checks, more evidence, and more governance overhead. The key is matching assurance to the transaction risk, not applying one standard everywhere.
  • Liveness Testing: Liveness testing is a biometric assurance control designed to determine whether the presented credential comes from a real, present person rather than a replay, photo, or spoof. In high-assurance identity systems, it is one of the controls that helps resist impersonation and fraud at enrolment or authentication time.
  • Verifiable Digital Credential: A verifiable digital credential is structured identity data that can be checked cryptographically by a relying party. Instead of relying on visual inspection, the verifier validates issuer signatures and presentation rules, which gives the control a clearer trust basis than an image-based document.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org