What is Identity Proofing?

That foundation matters more than it first appears. Every ensuing control inherits the assurance of the enrollment that created the account, which means a weak proofing process quietly caps the value of even the strongest authentication layered on top of it.

Identity proofing was once a specialized government requirement but has become a mainstream enterprise concern, driven by remote onboarding at scale, industrialized synthetic identity fraud, and generative AI tools that make forged documents and faces cheap to produce. This page explains how identity proofing works, how it differs from identity verification and authentication, the four types of identity proofing recognized by NIST, the identity assurance levels that measure it, and where it fits inside a modern manajemen identitas dan akses program.

Identity proofing is carried out by a credential service provider, or CSP, which may be a third-party vendor or the organization acting in that role for itself. NIST SP 800-63A, which outlines enrollment and identity proofing requirements, structures enrollment as three sequential steps followed by enrollment:

During the process, the CSP collects identity evidence and core attributes from the applicant. Resolution, validation, and verification are then performed in that order. Core attributes typically include first name, middle name or initial, last name, date of birth, and a physical or digital address at which the applicant can be reached, and the CSP must include at least one government identifier such as a Social Security number, driver’s license number, or passport number. On successful completion, the applicant becomes a subscriber with an account, and one or more authenticators are bound to that account. A notification of proofing is sent to a validated postal address or phone number, so that anyone who did not initiate the enrollment can dispute it.

The three steps sound similar and are routinely conflated, including by vendors. Keeping them distinct is what makes the rest of the topic tractable.

Identity resolution

Resolution answers whether the claimed identity corresponds to a single, unique, real person. It involves collecting the minimum evidence and attribute information needed to distinguish that individual, and because it is the first point of contact, it is also where fraud detection begins.

Identity validation

Validation answers whether the evidence and attributes are genuine, and it has two halves. Evidence validation confirms that a document or digital credential is authentic, meaning not forged or altered, as well as accurate and valid. Attribute validation confirms the accuracy of the core attributes against an authoritative or credible source.

The distinction between those two source types is worth knowing, since they are often treated as interchangeable. An authoritative source is the issuing source itself or has direct access to the records the issuing source maintains, such as a state department of motor vehicles for driver’s license data. A credible source maintains attribute information that can be traced back to an authoritative source, or correlates information from multiple sources for accuracy and currency and is subject to regulatory oversight.

Identity verification

Verification answers whether the applicant engaged in the process is the rightful owner of the validated evidence. This is the step most people have in mind when they say, “identity verification,” which is exactly why the two terms cause so much confusion.

These are not competing approaches. Identity verification is one step inside identity proofing, not an alternative to it.

• Scope: identity proofing is the full enrollment process, while identity verification is the single step that links a live person to validated evidence
• Question answered: proofing asks whether this identity exists and belongs to this applicant, verification asks whether this applicant is the rightful owner of the evidence presented
• Output: proofing produces an enrolled account at a stated assurance level, verification produces a pass or fail on the linkage
• Usage: in the vendor market, “identity verification” is often used loosely to describe the entire process, so the two terms frequently appear as synonyms even though the standard treats them differently

When a product is marketed as identity verification, the practical question is which of the three steps it actually performs. Some solutions handle resolution and validation but leave verification to the customer, and others do the reverse.

The cleaner distinction is between proofing and authentication, and it comes down to when each one happens:

• Identity proofing happens once, at enrollment, and establishes who the person is
• Otentikasi happens at every subsequent access attempt, and establishes that the returning user is the same person who was proofed
• Proofing assurance is measured by identity assurance levels, authentication assurance by authentication assurance levels, and the two are selected independently based on the risk of the service being protected

High-assurance authentication built on weak proofing produces a well-defended account that may not belong to the person it names. Account recovery is where that gap most often appears, because a reset path that accepts weaker evidence than the original enrollment lowers the effective assurance of the account no matter how strong the day-to-day authentication is. This is why help desk fraud has become one of the more productive attack paths against otherwise well-secured organizations.

NIST defines four types of identity proofing, distinguished by two factors: where the process takes place, and whether an agent of the CSP attends it.

• Remote unattended: resolution, validation, and verification are completely automated with no agent involved, on a device and in a location the CSP does not control
• Remote attended: the applicant completes the steps through a secure video session with a proofing agent or trusted referee, again on devices the CSP does not control
• On-site unattended: the process is fully automated, but takes place at a physical location and on a workstation or kiosk the CSP controls
• On-site attended: the applicant completes the entire process in the presence of a proofing agent or trusted referee, either co-located or through a controlled kiosk, at a CSP-controlled location

CSPs may also combine these into hybrid processes. A common pattern runs automated validation in advance of an attended session where verification takes place, which reduces the length of the attended session without lowering the assurance of the result.

Not all identity documents carry equal weight. Evidence strength is graded by the rigor of the issuing process, how reliably the evidence can be validated, and whether it can support one of the approved verification methods. The NIST standard defines three tiers.

• Fair: issued through formal procedures with delivery to the person it relates to, carrying the claimed name plus either a reference number, a biometric characteristic, or enough attributes to uniquely identify that person, and including security features that make reproduction difficult
• Kuat: adds recurring oversight of the issuing procedures by a regulatory or publicly accountable institution, and requires a facial image or other biometric characteristic on the evidence itself
• Superior: adds cryptographically protected attributes that can be validated through a digital signature applied by the issuing source, and requires that the issuing source confirmed the subject’s physical existence through an attended enrollment process

A state-issued driver’s license is the familiar example of strong evidence. Superior evidence is a narrower category, which is part of why emerging credential formats such as mobile driver’s licenses and verifiable credentials are drawing attention: they are digitally signed by the issuer and can be validated cryptographically rather than visually.

Assurance in a proofed identity is expressed as an identity assurance level, or IAL. Each level builds on the requirements of the one below it, so the levels are cumulative rather than parallel options.
Selecting a level is a risk decision, not a matter of defaulting to the strictest available option. Applying the highest level to a service that does not need it adds enrollment friction and operational cost while excluding legitimate users, and it consumes the budget needed to implement high assurance properly where it genuinely matters.

No identity proofing

At the baseline, there is no requirement to link the applicant to a specific real-life person. Evidence collection is not required, attributes may or may not be validated, and verification is not conducted. This is an appropriate choice when a fabricated identity would cause minimal harm to the service or its users, and it is a risk judgment rather than a security failure.

Identity assurance – Level 1 (IAL1)

At IAL1, the proofing process supports the real-world existence of the claimed identity and provides some assurance that the applicant is associated with it. Core attributes are obtained from evidence or self-asserted by the applicant, but all of them are validated against authoritative or credible sources, and steps are taken to confirm the attributes belong to the person being proofed.

Evidence requirements at IAL1 are satisfied by one piece of fair evidence that can be digitally validated or that carries a facial portrait or other biometric, or by a single piece of strong or superior evidence. Any of the four proofing types may be used, attended or unattended, and biometric matching is optional. IAL1 is designed to limit highly scalable attacks such as automated enrollment, and to protect against synthetic identities and the use of compromised personal information.

Identity assurance – Level 2 (IAL2)

IAL2 requires collecting additional evidence and applying more rigorous processes for validating that evidence and verifying identities, including enhanced steps to confirm the applicant is the rightful owner of what they presented.
One detail is widely reported incorrectly: like IAL1, identity proofing at IAL2 can be performed remotely or on-site, attended or unattended. IAL2 does not require an in-person visit. It is designed to limit scaled and targeted attacks, and to protect against basic evidence falsification, evidence theft, and social engineering.

Identity assurance – Level 3 (IAL3)

IAL3 adds two requirements to IAL2. A trained CSP representative, called a proofing agent, must interact directly with the applicant as part of an on-site attended session, and at least one biometric characteristic must be collected. The on-site session may use either a co-located agent or a kiosk-based agent. A successful session concludes with enrollment and the delivery of one or more authenticators bound to the account.

IAL3 targets sophisticated attacks, including advanced evidence falsification, theft, repudiation, and more advanced social engineering.

What changed in NIST SP 800-63A – Revision 4

Revision 4 was published in July 2025 and supersedes the June 2017 edition, which had last been updated in March 2020. Because much of the material written about identity proofing still describes the earlier revision, several widely repeated statements are now out of date.

• IAL1 was repurposed as a proofing level in its own right, and the case where no proofing is required is now described as a separate baseline rather than as IAL1
• IAL3 is an on-site attended process, so the supervised remote path that older summaries attribute to IAL3 no longer applies
• Knowledge-based verification is no longer permitted as an identity verification method
• New requirements were added for digital injection prevention and forged media detection
• CSPs are now required to establish and maintain a fraud management program, with documented fraud checks and defined handling of failures

The standard specifies the acceptable ways of establishing the linkage between validated evidence and the live applicant.

• Confirmation code verification: the applicant demonstrates control of a piece of evidence by returning a code sent to a validated address or phone number
• Authentication and federation protocols: the applicant demonstrates control of a digital account, such as an online bank account, or of a signed digital assertion
• Transaction verification: the applicant returns a value based on a microtransaction between the CSP and the issuing source, such as a micro-deposit used to confirm ownership of a financial account
• Visual facial image comparison: a trained proofing agent compares the facial image on the evidence to the applicant, either in an on-site session or remotely
• Automated biometric comparison: an algorithm compares a biometric sample captured during the session to the biometric on the evidence or held in authoritative records

Confirmation codes carry their own constraints. They must contain at least six decimal digits or the equivalent, and they expire quickly: ten minutes when sent to a validated phone number, twenty-four hours by email, twenty-one days to a postal address within the contiguous United States, and thirty days to a postal address outside it.

Security questions are no longer an acceptable method

Knowledge-based verification, the familiar pattern of asking about a former address or a past car loan, may no longer be used to verify identity under SP 800-63A-4. The reasoning is straightforward, since the personal history those questions draw on has been exposed in breaches often enough that knowing the answers no longer indicates ownership of the identity.

The prohibition is specific rather than blanket. Knowledge-based checks may still be used as one input to a fraud management program. What they cannot do is stand in for verification, which means any enrollment or account recovery flow still relying on security questions to establish identity is operating below the current standard.

Biometric performance requirements

Where biometrics are used, the standard sets measurable thresholds rather than leaving performance to vendor claims. For one-to-one comparison against a claimed identity, the false match rate must be 1 in 10,000 or better and the false non-match rate 1 in 100 or better. Remote biometric collection requires presentation attack detection meeting an impostor attack presentation accept rate below 0.07. Performance for any demographic group may be no more than 25 percent worse than performance for the overall population, measured with a fixed threshold, and results must be made publicly available.

Remote proofing faces a threat that biometric comparison alone does not address. Injection attacks insert forged or modified media between the capture device and the system performing the comparison, so a successful injection bypasses the capture step entirely. Paired with generative AI tools, the forged media itself is now inexpensive and convincing, whether it targets automated document validation, automated biometric matching, or the video feed a human proofing agent is watching.

Countermeasures work in layers rather than as a single control:

• Confirming that digital media originates from a genuine sensor, including checks for virtual cameras, device emulators, and jailbroken devices
• Analyzing all submitted media for artifacts of modification, manipulation, or forgery, with manual review augmenting automated decisions
• Live document capture with document presence checks, so the item is confirmed physically present rather than a manipulated copy
• Random human-in-the-loop cues during attended remote sessions, such as requesting a specific movement, which are harder to satisfy with pre-generated media
• Broader fraud checks, including a required death records check, alongside SIM swap detection, device and account tenure checks, mailing address risk checks, device fingerprinting, and transaction analytics

Identity proofing obligations arise wherever the consequences of admitting the wrong person are severe.

• Government agencies and their contractors, where a digital identity risk assessment determines the assurance level required for a given service, and where additional privacy obligations attach to the collection of personal and biometric data
• Layanan keuangan, where customer identification and know-your-customer obligations require verifying the identity of account holders at onboarding
• Healthcare, where patient identity proofing supports portal enrollment, records access, and electronic prescribing, and where a mismatched record carries clinical as well as privacy risk
• State benefits programs, which have absorbed sustained synthetic and stolen identity fraud
• Regulated sectors facing operational resilience and access control requirements, where the strength of enrollment is increasingly examined alongside the strength of authentication

Assurance and access pull against each other. Raising evidence requirements excludes legitimate applicants who cannot produce that evidence, which is why the standard treats exception handling as a design requirement rather than an afterthought. It defines trusted referees, who are trained to make risk-based decisions for applicants unable to meet the normal requirements, and applicant references, who can vouch for an applicant’s identity, attributes, or circumstances. Those paths matter for people without conventional documentation, including individuals displaced by disaster, people experiencing homelessness, older applicants, and minors.

Several practices follow from that:

• Match the level to the risk, since over-proofing costs money and users without returning security value
• Offer more than one proofing type and accept multiple evidence combinations, so a single failure mode does not lock people out
• Treat privacy as part of the design, with data minimization, explicit notice at collection, documented biometric retention and deletion, and consent recorded for biometric use
• Set reverification policy deliberately, and make sure account recovery does not accept weaker evidence than the original enrollment
• Monitor fraud check performance over time, because effectiveness shifts with the threat environment and with the applicant population

Identity proofing is the root of trust for the identity lifecycle. Authentication, authorization, and tata kelola identitas all inherit the assurance of the enrollment that created the account, so an identity program that invests heavily in access control while treating enrollment as a form to fill out has built strength on an unverified foundation.

Most enterprises do not operate proofing themselves. They consume it from a CSP or a verification provider, which makes the part they own the binding between the proofed identity and the authenticators issued to it. That binding is where assurance is either preserved or lost over time. A phishing-resistant authenticator bound at enrollment keeps the proofing result meaningful, while a weakly bound credential can be replaced by an attacker without any further proofing, which silently discards whatever the enrollment established.

High-assurance and regulated environments add constraints that cloud-only approaches handle poorly. Proofed identities have to be bound to authenticators and governed consistently across cloud, hybrid, on-premises, and air-gapped systems, under data sovereignty rules that may restrict where identity data can be processed at all, and in conditions where an external verification service may be unreachable when access is needed.

RSA binds proofed identities to phishing-resistant authenticators and applies consistent assurance policy across those environments. RSA ID Plus delivers authentication and access across cloud, hybrid, and on-premises deployments, with offline authentication for environments where the cloud cannot be reached, while manajemen postur keamanan identitas surfaces the gaps between the assurance an organization believes it has and the assurance its accounts actually carry.