Identity proofing is the process that happens before a credential ever gets issued. Before a user receives a PIV card, a username, or any form of authenticated access, someone or some system has to verify that the person claiming an identity is actually who they say they are. In federal environments, that verification process carries real weight. A failure at this stage does not just create a security gap. It undermines the entire trust model that downstream authentication, authorization, and access control depend on.
Most organizations talk extensively about multi-factor authentication, zero trust architecture, and privileged access management. Those conversations are necessary. But they assume identity proofing was done correctly upstream. When it was not, the credential you are authenticating may belong to someone you never actually vetted. The access you are controlling may be granted to an identity that was never verified against a real person in the first place.
Federal agencies operate under specific guidance here. NIST Special Publication 800-63A defines Identity Assurance Levels, known as IAL1, IAL2, and IAL3, that establish how rigorously an identity must be proofed before a credential can be issued at a given trust level. These levels are not suggestions. They map directly to the types of credentials agencies can issue and the types of systems those credentials can access. Getting this right requires coordination across HR, security, IT, and sometimes legal, and most agencies are doing parts of it well while quietly struggling with others.
This article focuses on identity proofing in federal contexts: what it actually involves, where agencies most commonly run into trouble, how NIST’s IAL framework applies in practice, and what a realistic approach looks like when you factor in contractors, remote workers, legacy systems, and the ongoing pressure to onboard people faster than your adjudication process can move.
If you have ever watched a contractor sit idle for three weeks waiting on a PIV card or seen an agency issue temporary network credentials that never got revoked, you already understand why this topic matters more than most IAM conversations acknowledge.
Key Takeaways
- Identity proofing establishes the trust foundation that all downstream authentication and access control depends on. Weak proofing at enrollment creates compounding risk that no authentication mechanism can fully compensate for.
- NIST SP 800-63A defines three Identity Assurance Levels, IAL1 through IAL3, that govern how rigorously an identity must be verified before a credential can be issued. Federal agencies must match their proofing process to the IAL required by the systems that credential will access.
- Remote identity proofing introduces additional complexity, particularly for contractors and mission partners who may never appear in person. Agencies must evaluate whether their remote proofing workflows actually meet the IAL requirements tied to the systems involved.
- Temporary credentials issued during the onboarding gap between hire and PIV card issuance represent one of the most common and underacknowledged identity risks in federal environments.
- Identity proofing is not a one-time event. Re-proofing requirements, identity record maintenance, and lifecycle management are ongoing obligations that most agencies have not fully operationalized.
- Effective identity proofing requires alignment between HR, security, IT operations, and the credential service provider. When those functions operate in silos, gaps appear at the seams.
Table of Contents
What Identity Proofing Actually Means in Federal Contexts
Identity proofing is the process of verifying that a claimed identity corresponds to a real, uniquely identifiable person before issuing that person a credential. It is distinct from authentication, which verifies that the person presenting a credential is the same person the credential was issued to. Proofing happens at enrollment. Authentication happens at every subsequent access attempt. The quality of your authentication depends entirely on the quality of your proofing.
In federal environments, identity proofing typically involves three components: resolution, validation, and verification. Resolution means you can distinguish this individual from others, typically by collecting name, date of birth, address, and identifying numbers. Validation means you can confirm that the identity documents or data provided are genuine and that they belong to the claimed identity. Verification means you can bind that validated identity to a specific physical person, either by checking documents in person, using biometrics, or employing a trusted remote proofing process.
Where federal agencies often fall short is treating identity proofing as a checkbox in a broader onboarding workflow rather than as a security control in its own right. The background investigation process, which has its own set of delays and constraints, sometimes gets conflated with identity proofing. They are related but not the same thing. A background investigation assesses suitability and trustworthiness over time. Identity proofing establishes that the person you investigated is the person showing up at the help desk requesting access.
The practical reality in most agencies is that identity proofing happens at PIV enrollment and is generally handled well for full-time federal employees. The problems emerge at the edges: contractors who may work remotely, temporary employees who receive non-PIV credentials, mission partners from other agencies or coalition environments, and privileged users who get elevated access through a separate workflow that may not have the same proofing rigor.
Every access decision you make downstream, every policy enforcement point you configure, every conditional access rule you write, rests on the assumption that the identity in your directory reflects a verified person. When that assumption is wrong even for a small subset of accounts, the consequences can be significant, particularly when those accounts belong to privileged users or systems with broad access.
NIST Identity Assurance Levels: IAL1, IAL2, and IAL3
NIST SP 800-63A defines three Identity Assurance Levels that govern how thoroughly an identity must be proofed before a credential at a corresponding level can be issued. These levels are not bureaucratic abstractions. They reflect a practical risk framework: the higher the sensitivity of the systems and data being accessed, the more rigorous the proofing process must be. Federal agencies are expected to map system access requirements to the appropriate IAL and ensure their proofing processes meet those requirements.
IAL1: Self-Asserted Identity
At IAL1, there is no requirement that an applicant prove their real-world identity. The attributes provided are self-asserted and are not validated against any authoritative source. IAL1 is appropriate for low-risk applications where the consequence of a false identity claim is limited. In federal environments, this might apply to public-facing applications where users are interacting with general information rather than sensitive agency data. Most federal systems requiring any level of authenticated access to sensitive information should not be relying on IAL1 credentials.
IAL2: Evidence-Based Remote or In-Person Proofing
IAL2 requires that identity evidence be validated and that the applicant be verified as the owner of that evidence. This can be accomplished remotely using identity documents and biometric comparison or in person. IAL2 is the level most commonly associated with federal civilian employee and contractor credentialing outside of PIV. It requires that evidence be checked against authoritative sources and that the claimed identity be bound to the person presenting it. Remote proofing at IAL2 is allowed but requires specific controls, including document authentication and facial comparison against a trusted source.
IAL3: In-Person Proofing with Physical Document Inspection
IAL3 requires in-person proofing by a trained representative who physically inspects identity documents. Biometric collection is required. This level is associated with federal PIV credentialing, where the applicant must appear before a credentialing officer, present qualifying identity documents, and have biometrics collected and linked to their credential. IAL3 provides the highest assurance that the credential belongs to the person it was issued to, which is why PIV authentication is required for logical access to federal information systems under HSPD-12 and the associated standards.
The practical challenge agencies face is that many of their systems were built with assumptions about IAL3 proofing via PIV, but the user population accessing those systems often includes non-PIV users who went through a lighter proofing process. When an agency issues a username and password to a contractor who self-reported their identity through an onboarding form, and that contractor then accesses systems that were designed for IAL3-proofed users, there is a mismatch that does not get surfaced in most audit processes.
Practitioner Reality
Many agencies treat PIV issuance as the finish line for identity proofing. In practice, PIV issuance covers IAL3 proofing for federal employees but says nothing about the identity assurance of the contractor who is using a username and password because their sponsoring office never got around to requesting a PIV. That account, which often has the same access as a PIV-enabled user, went through whatever proofing the help desk required when they called in, which is usually not much. The gap between what your PIV policy says and what your non-PIV population actually went through is where most identity proofing risk lives.
| Identity Assurance Level | Proofing Method | Evidence Required | Biometrics | Typical Federal Use |
|---|---|---|---|---|
| IAL1 | Self-asserted, no validation | None required | Not required | Public-facing, low-risk applications |
| IAL2 | Remote or in-person with document validation | Identity documents validated against authoritative sources | Required for remote proofing (facial comparison) | Non-PIV contractor and partner credentialing |
| IAL3 | In-person with trained officer and physical document inspection | Strong identity evidence, physically inspected | Required (collected and bound to credential) | PIV credentialing, high-assurance federal access |
Remote Identity Proofing and the Contractor Problem
Remote work fundamentally changed the calculus around identity proofing in federal environments. Before widespread remote work, the assumption was that most credentialing events happened in person. Someone showed up at a badging office, presented documents, got photographed, and walked away with a PIV card. That model is increasingly unrealistic for a workforce that includes geographically distributed contractors, part-time personnel, and mission partners who may never physically visit an agency facility.
The contractor population is where most agencies encounter the hardest identity proofing problems. A contractor may be sponsored by a program office, approved through a contracting vehicle, and granted network access through IT, with each of those functions operating on its own timeline and with its own documentation requirements. The result is often that the person who eventually receives credentials was proofed adequately for the contracting process but not necessarily for the credentialing process, and the two tracks never actually compared notes.
NIST SP 800-63A allows IAL2 proofing to be conducted remotely, but the requirements are specific. The applicant must submit identity documents that can be authenticated digitally. A facial comparison must be performed against the document photo or against a reference biometric from a trusted source. Liveness detection is expected to prevent presentation attacks. These are not trivial capabilities to deploy, and many agencies that believe they are conducting IAL2 remote proofing are actually conducting something lighter than that because they lack one or more of these components in their workflow.
The practical gap is significant. An agency might require contractors to submit a copy of a government-issued ID via email and then have an IT support staff member visually review it before issuing credentials. That process may satisfy an administrative requirement without meeting any defined IAL. The ID was not authenticated against an authoritative source. No biometric comparison was performed. No liveness check was conducted. Yet the contractor receives credentials that may grant access to sensitive systems.
Some agencies have begun integrating identity verification platforms into their onboarding workflows to close this gap. These platforms can handle document authentication, facial comparison, and liveness detection in a way that satisfies IAL2 remote proofing requirements. The challenge is connecting those platforms to the downstream credentialing workflow so that the proofing record is captured, retained, and linked to the credential that gets issued. Many agencies can execute the proofing step but cannot demonstrate the chain of evidence afterward, which creates audit exposure.
How Identity Proofing Supports Authentication
Authentication verifies a credential. Identity proofing verifies a person. The relationship between them is sequential and foundational. When you authenticate a PIV card, you are confirming that the card is valid and that the person presenting it possesses the private key associated with the certificate on the card. That confirmation is only meaningful if the PIV card was issued to the right person, which requires that identity proofing was conducted correctly at enrollment. Authentication cannot repair a broken proofing process. It can only faithfully confirm what the proofing process established.
This dependency is why identity and access management (IAM) programs that focus heavily on authentication mechanisms without addressing proofing rigor often find themselves with gaps that neither zero trust architecture nor multi-factor authentication can close. You can require the strongest available authenticator and still be authenticating an identity that was never properly verified. The credential is genuine. The identity behind it may not be.
In zero trust models, where every access request is evaluated based on identity context, device posture, and session behavior, the quality of the identity signal matters more, not less. A zero trust policy engine that evaluates access requests assumes that the identity assertions it receives are trustworthy. If the identity record in the directory was created for someone whose proofing was insufficient, the policy engine will make access decisions based on a flawed identity signal. Strong authentication of a weakly proofed identity does not produce a trustworthy access decision.
This matters practically in several scenarios. When an insider threat program flags anomalous behavior associated with an account, the response depends on being able to accurately attribute that account to a known, verified individual. When an incident response team investigates unauthorized access, the forensic value of authentication logs depends on the assumption that the account was issued to a verified person. When an auditor asks for evidence of access controls, the answer “we require PIV authentication” is incomplete if non-PIV accounts with equivalent access were proofed through a process that would not satisfy any defined IAL.
The operational takeaway is that identity proofing is not a pre-security step that happens before the real IAM work begins. It is the first security control in the credential lifecycle. Decisions about what proofing level to require, how to conduct it, and how to maintain the evidentiary record are security decisions that affect every access control you build on top of them.
Federal Identity Proofing Quick Reference
Proofing Components
Resolution: Distinguish the individual
Validation: Confirm documents are genuine
Verification: Bind identity to the person
IAL Requirements
IAL1: Self-asserted, no validation required
IAL2: Validated evidence, remote or in-person
IAL3: In-person, physical documents, biometrics
High-Risk Populations
Remote contractors
Non-PIV users with sensitive access
Mission partners and federated users
Lifecycle Obligations
Retain proofing evidence records
Re-proof on role change or re-enrollment
Revoke promptly on separation or sponsorship end
Common Mistakes in Federal Identity Proofing Programs
The most consistent mistake is treating PIV issuance as the complete solution to identity proofing without addressing the non-PIV population. Agencies with mature PIV programs often have excellent proofing practices for their federal employee population and much weaker practices for contractors, temporary staff, and privileged service account owners. The PIV program satisfies auditors. The non-PIV population is where the actual risk accumulates.
A closely related problem is the onboarding gap. Between the time a user is granted access pending PIV issuance and the time they actually receive and activate their PIV card, they typically operate on temporary credentials. Those credentials may have been issued with minimal proofing. They frequently have access comparable to what the user will have post-PIV. And they often persist far longer than intended because no one owns the process of monitoring pending PIV activations and revoking interim access once the card is issued or if issuance falls through.
Another common failure is not maintaining the proofing record. NIST SP 800-63A requires that agencies retain specific evidence of the proofing transaction, including what documents were presented, how they were validated, and what biometrics were collected. Many agencies can confirm that a PIV was issued but cannot reconstruct the chain of evidence from the proofing event. This matters when an account is associated with an incident or when an auditor or inspector general requests documentation of the proofing process.
Re-proofing is another area that receives little attention. Identity proofing is typically thought of as a one-time event at credential issuance, but there are circumstances where re-proofing is warranted. When a credential is lost or stolen, when a user changes roles significantly, or when a long-term credential is renewed after an extended gap, re-proofing the underlying identity makes sense operationally. Few agencies have defined triggers for re-proofing or processes to execute it.
Finally, some agencies conflate identity proofing with background investigation. A completed background investigation is evidence of suitability and trustworthiness. It is not a substitute for identity proofing. The background investigation tells you about the person’s history. Identity proofing tells you that the person in front of you is actually the person that history belongs to. Both are necessary. Neither replaces the other.
Recommended Federal Approach
Start by mapping your access population against your IAL requirements. Not every user needs IAL3. But every user needs to be proofed at a level that matches the sensitivity of what they can access. If your systems require PIV authentication, the users of those systems need IAL3-equivalent proofing. If you are issuing non-PIV credentials for any reason, you need to define what IAL those credentials represent and verify that your proofing process actually meets that standard.
For contractors and remote personnel, evaluate whether your current remote onboarding workflow meets IAL2. If it relies on email submission of identity documents without automated authentication and biometric comparison, it probably does not. Agencies that need to proof remote users at IAL2 should consider integrating a purpose-built identity verification platform into the onboarding workflow and ensuring that the output of that platform, the proofing record, is retained and linked to the credential that gets issued.
Address the onboarding gap explicitly. Define a maximum duration for interim credentials, document what access those credentials are permitted to have, and build a workflow that either confirms PIV issuance and triggers revocation of interim credentials or escalates for review if the PIV process stalls. This does not require expensive tooling. It requires someone to own the process and a mechanism to surface accounts in the interim credential state beyond a defined threshold.
Build cross-functional ownership. Identity proofing touches HR for employment verification, security for adjudication and suitability, IT for credentialing and directory management, and in many cases legal for privacy implications of biometric data collection. Agencies that struggle most with identity proofing are those where each function owns a piece of the process without anyone owning the end-to-end chain. Designating a process owner who can see the full workflow from enrollment request to credential issuance to record retention resolves most of the gaps that audits surface.
Plan for lifecycle management. Define what triggers a re-proofing event. Build a process to execute re-proofing when those triggers occur. Ensure that proofing records are retained in accordance with the records management requirements that apply to your agency. These are not glamorous activities, but they are the difference between an identity proofing program that satisfies an initial audit and one that holds up under sustained scrutiny or an actual incident investigation.
The agencies that handle identity proofing well tend to approach it the same way they approach any other security control: they define the requirement, assess their current posture against it, identify gaps, prioritize remediation by risk, and build processes that are repeatable and auditable. The technology is available to support all of this. The harder work is organizational, which is the same thing that is true of most meaningful security improvements in federal environments. Visit Anchor Defense solutions to explore how we support federal identity and access programs across the credential lifecycle.
Need help evaluating solutions for your environment?
Whether you’re modernizing infrastructure, improving resilience, or evaluating technologies, Anchor Defense helps organizations align mission requirements with practical outcomes.