PR.AA-02 Identity proofing: requirements and evidence

What PR.AA-02 identity proofing requires in NIST CSF 2.0

PR.AA-02 asks that identities be verified and bound to credentials in a way that fits the context of each interaction. If you are running a CSF 2.0 assessment or a customer has asked you to show alignment, the question to answer is whether you can say, for each class of user, how you know a person is who they claim to be before they receive a credential, and whether that one credential belongs to one person only. PR.AA-02 is a Subcategory of the Identity Management, Authentication, and Access Control (PR.AA) Category in the PROTECT Function, and it takes over the CSF 1.1 PR.AC-6 outcome under a new identifier, so teams mapping an older assessment should move that evidence across rather than start over.

The risk is account impersonation. If enrollment accepts an unverified name or email address, an attacker can obtain a legitimate account that the organization then trusts. Shared credentials create a quieter version of the same problem: when several people use one login, actions cannot be attributed and access cannot be revoked for one person without affecting the others. NIST publishes two Implementation Examples for this Subcategory: verify a claimed identity at enrollment with government-issued credentials such as a passport or driver's license, and issue each person a separate credential with no sharing. These examples illustrate the outcome. NIST sets outcomes, not procedures, so the organization decides what proofing level fits a contractor with privileged access compared with a read-only employee, and documents that decision. An independent assessor will test whether the decision was made and applied, not whether it matches a template.

Proofing is hard because enrollment is not owned by one team. HR often starts the identity record, the service desk resets credentials and resolves lost-access cases, and vendors or staffing agencies onboard their own people into shared systems. Each path can skip the proofing step unless it is written into the procedure for that path. Confirm with your HR, service desk and key vendors who can create an identity, what evidence each path collects, and whether the same person can ever hold two accounts. Keep the records that show the check happened, such as the enrollment ticket, the verification method used and the credential issuance log, because those records are what an assessor will sample.

Which identities and enrollment paths does PR.AA-02 cover?

PR.AA-02 applies to every identity that gets a credential, but the proofing bar should not be the same for each one. The cards below separate the enrollment paths and risk levels that change how much verification a credential needs, so you can scope the work before anyone selects a method.

Workforce onboarding

Employees and staff are usually proofed at hire, often through HR records, an in-person check, or a verified background process. The key decision is who performs the identity check and where its result is recorded. Confirm that the identity verified at enrollment is the one bound to the directory account, and that the binding survives transfers and rehires. Your identity provider or directory should hold the proofing record or a reference to it, so an assessor can trace a credential back to a specific verification event.

Customer and citizen enrollment

External users often enroll remotely, which means no staff member sees the person or the original document. Decide which identity evidence you accept, such as a government-issued document or an account already verified by another trusted service, and document the fallback when evidence cannot be checked. Record what was verified, when, and by which method, because remote enrollment is the path most often questioned after a fraud incident.

Contractors and third-party accounts

Contractors and vendor staff often hold access without being employees, and their proofing may sit with an employer you do not control. Define whether you accept the supplier's verification, what evidence you require from them, and when their accounts expire. Confirm that each individual has a personal account, since shared vendor logins fail the one-credential-per-person expectation in the Implementation Examples.

Privileged and emergency accounts

Administrators, break-glass accounts and recovery identities carry the highest impact if misused, so their proofing needs stronger evidence and a tighter record than standard users. Check how privileged identities are created, who approves them, and whether emergency accounts are tied to a named person rather than a generic role. Test whether a locked-out administrator can recover access without a path that bypasses proofing.

Service and non-human identities

Service accounts, workloads and devices do not present a passport, so proofing for them means establishing which system or owner the identity belongs to and who authorized it. Record the owning team, the purpose and the issuing process for each non-human identity. Avoid credentials that many services share, because a shared secret cannot be tied to one accountable identity in an assessment.

Risk level of the interaction

PR.AA-02 asks for identity checks that match the context of each interaction, so the same user may need different proofing for a low-value read and a high-value transfer. Set a small number of risk levels, map each enrollment path and high-impact action to one of them, and state the evidence required at each level. Review the mapping when a new system or data type is added, because the level chosen at enrollment often determines what an assessor will sample.

How an assessor tests identity proofing

This table compares what an assessor samples, reviews, traces and typically finds when testing PR.AA-02 identity proofing. Read each row as a test step: the evidence it needs from your team and the gap that most often causes a finding.

Test area	What the assessor does	Evidence requested	Common findings
Enrollment record sampling	Selects a sample of recent account creations and checks each for a recorded proofing step	Enrollment tickets, identity verification logs, timestamps and the operator who completed each step	Records missing the proofing step, or accounts created through a path that skipped it
Proofing procedure review	Compares the written procedure with the risk of each interaction, such as employee onboarding, customer sign-up or privileged admin access	Approved procedure, risk tiers that set the proofing strength, and version history	Procedure does not distinguish high-risk interactions, or was never approved or reviewed
Government ID evidence	Checks that the proofing method for in-scope identities uses evidence the organization can show it reviewed	Copies or verification results of accepted documents, and the method used to check them	Evidence retained inconsistently, or no record of who judged the document authentic
Duplicate identity checks	Looks for one person holding several accounts or credentials that were never linked to a verified identity	Identity registry extracts, matching rules and results of duplicate searches	Accounts created from the same person with no reconciliation or merge record
Shared or reused credentials	Tests whether a credential is issued to one person only and whether shared accounts are tracked	Credential issuance records, inventory of shared or service accounts and their named owners	Generic accounts used by several staff with no accountable owner or issuance record
Account to person tracing	Picks active accounts and traces each back to an approved identity record and a verified person	Identity lifecycle records linking accounts, HR or customer records and proofing outcomes	Orphaned accounts with no traceable proofing event, or links that cannot be followed end to end
Exceptions and remediation	Reviews approved exceptions, such as manual proofing or sponsored enrollment, and how they were closed	Exception register, approvals, compensating controls and closure evidence	Exceptions that never expire or lack a named approver

How to implement identity proofing step by step

This sequence turns PR.AA-02 from a policy statement into a working enrollment process, with each step producing a record an assessor can trace. It starts from the enrollment paths people actually use and ends with a sample test of real enrollments.

Map enrollment paths and interaction risk
List every way an identity enters your environment: employee onboarding, contractor sponsorship, customer sign-up, partner accounts, privileged administrator accounts and account recovery. For each path, note who initiates it, what the person can access afterward and what damage a false identity could cause. The output is an enrollment register with one row per path and a risk rating that explains the rating. Confirm the list with HR, customer onboarding and the service desk, because the paths that matter most are often the informal ones.
Define the proofing method for each path
For each row in the register, decide how strong the identity check must be. A low-risk path may rely on a verified manager sponsorship, while a privileged or financial path may require in-person review of a government-issued photo ID. Write the method, the evidence accepted, the person who performs the check and the record kept. Ask legal and HR to confirm that the method is permitted in each jurisdiction where you enroll people. The output is an approved proofing standard that maps each enrollment path to a method.
Set one-credential-per-person rules
Configure the identity provider so that each person has one primary account, and that account is bound to credentials issued to that person only. Block shared logins for individuals, require a documented exception with an owner for any shared or service account, and check for duplicate identities before a new account is created. Test the duplicate check with known duplicate records. The output is a written credential rule set and a directory configuration that enforces it, with exceptions listed and reviewed.
Integrate proofing into HR and service desk workflows
Connect the proofing step to the systems that trigger it. HR should start onboarding only after the proofing step is complete, and the service desk should follow the same method before resetting credentials or issuing new ones. If your identity platform uses SCIM provisioning, such as the authentik SCIM provider, confirm that accounts created by the source system are linked to the proofing record rather than created as unverified accounts. The output is a documented workflow for each trigger and a test showing that a new hire or a password reset cannot skip the proofing step.
Record outputs at each step
Decide what evidence each step leaves behind before the first enrollment runs. Typical records include the proofing method used, the date, the name of the verifier, a reference to the document checked (not a copy of the document unless your privacy assessment allows it), the credential issued and the identifier it is bound to. Store these records in a system with access control and retention rules that your privacy and legal teams approve. The output is a defined evidence set per enrollment path that an auditor can sample.
Test with a sample of real enrollments
Select a sample of recent enrollments across every path, including at least one privileged account and one service desk reset, and trace each one from the proofing record to the active credential. Check that the method matched the standard, that the verifier was authorized, that no second credential exists for the same person and that the record is complete. Record every exception and assign a corrective action with an owner. The output is a written test report and a corrective action list that you can show to your independent assessor, who will decide whether the control operates as described.

Evidence that shows identity proofing works

Identity proofing is only credible when the organization can show how each identity was checked, what was bound to it, and how that binding stayed accurate over time. The cards below cover the records an assessor will sample for PR.AA-02, and the routine checks that keep them current between formal reviews.

Written proofing procedure per path

Keep one procedure for each way an identity enters the organization, such as employee onboarding, contractor sponsorship, customer enrollment and service account creation. Each procedure should name the documents or checks accepted, who performs the check, what happens when a check fails, and which system records the outcome. Assessors compare the procedure with what staff actually did, so the document must match the workflow in the identity platform. Review it whenever an enrollment path changes.

Records of verified identity checks

Retain a record showing that the claimed identity was checked against an acceptable source, such as a government-issued passport or driver's license for in-person enrollment, or the result of a documented remote verification. Store the verifier, date, method and result, but minimize copies of the underlying identity documents under your privacy obligations. Confirm with your privacy counsel how long these records are kept. A sampled identity with no verification record is the most common gap assessors raise.

Identity-to-credential binding logs

Log each event that links a verified identity to a credential, including the account identifier, the credential type, the issuing system and the approver for any manual step. The log should show that one credential was issued to one person and that the binding happened after proofing, not before. Export these events to a central log store so the sequence can be reconstructed for any sampled user. Check that administrators cannot edit or delete entries without leaving a trace.

Duplicate account reports

Run a recurring report that matches accounts on attributes such as legal name, date of birth, employee number, email address and verified document identifiers, then lists possible duplicates for review. Duplicates are where one person holds two credentials, which the Implementation Examples for PR.AA-02 specifically target by calling for one credential per person with no sharing. Record each finding, its disposition and the date it was closed. Ask your platform team how the matching rules were tested before you rely on them.

Exception approvals for proofing

Some cases will fall outside the standard path, such as a shared kiosk account, a returning contractor without current documents, or an emergency access request. Record each exception with the business reason, the compensating check, the approver with the authority to accept the risk and an expiry date. Assessors look for exceptions that never expire or that were approved by the same person who requested them. Review open exceptions at the same cadence as access reviews.

Provisioning and deprovisioning records

Keep timestamped records of account creation, attribute changes and removal, together with the authoritative event that triggered each one, such as an HR hire or termination. Open-source identity providers can push these changes to downstream applications; authentik's SCIM provider, for example, runs a full sync every hour and deprovisions users from target applications when they lose access. Confirm the sync interval and deprovisioning behavior in your own configuration, and sample a few leavers to check the timing against your procedure.

What identity proofing costs in money and effort

This table compares the main cost components of identity proofing for PR.AA-02, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request and to decide which parts to keep in-house. No prices are given because none are supplied for this topic.

Cost component	Who is paid or who carries the effort	One-time or recurring	What drives it up or down
Process design	Internal risk and HR owners, with an advisor if one is engaged	One-time, revisited when enrollment paths change	Number of enrollment paths and populations, such as employees, contractors and customers
Verification tooling or licenses	Vendor of any commercial document or identity verification service	Often recurring per check or per seat; confirm the pricing model	Volume of enrollments and number of document checks per person; open-source identity providers can reduce license spend but still need hosting and integration
Enrollment staff time	Internal registration or help desk staff who inspect documents or run in-person checks	Recurring with each enrollment and re-proofing event	Share of enrollments that need manual review versus automated checks
Directory and provisioning engineering	Internal platform engineers or an implementation partner for self-hosted directories and provisioning	One-time build, then recurring upkeep and upgrades	Number of target applications and whether provisioning is automated end to end, for example over SCIM
Evidence upkeep	Internal compliance or GRC staff who retain enrollment records and proofing logs	Recurring for the life of each identity and the retention period set by policy	Retention rules, record volume and how well logs are indexed for sampling
Auditor sampling	Independent auditor or assessor, billed by the engagement	Recurring at each assessment cycle	Number of identities sampled, quality of records, and how quickly evidence can be produced

How authentik and FreeIPA support proofed identities

The authentik SCIM provider pushes user and group records from authentik to target applications over SCIM 2.0. For PR.AA-02, the useful property is that a identity created only after the organization's proofing step is carried into downstream applications without manual re-entry, and the same identity is removed when access ends. The provider does not check a passport or driver's license; that verification is a process step the organization runs and records before the account is created.

Creations, changes and deletions: the provider sends new users and groups, attribute changes and removals to each connected application.
Hourly full sync: authentik runs a full synchronization every hour, which reconciles target applications with the source even when an individual event was missed.
Deprovisioning: users who lose access to an application are removed from that target, so accounts do not outlive their authorization.
Evidence produced: provider configuration, sync logs and deprovisioning records show that each downstream account traces to a source identity.
License: authentik is released under the MIT license, so confirm any commercial add-ons or support terms separately.

Confirm with your platform team how the provider handles failed pushes, which applications support SCIM 2.0 in your environment, and where the sync logs are retained for your assessor.

Where identity proofing programs usually fall short

Identity proofing rarely fails in the moment of enrollment. It fails in the gaps around it: shared accounts, inconsistent checks, records that never reach the directory, and access that outlives the reason it was granted. The cards below cover the gaps assessors most often probe for PR.AA-02 and a practical fix for each.

Shared service accounts used by people

A shared login used by several staff members cannot be bound to one person, so PR.AA-02 fails at its core: one credential per person with no sharing. Typical cases include a shared administrator login for a ticketing system or a team mailbox used to sign into an application. Inventory accounts that a human uses interactively, separate them from true service accounts, and give each person a named account with its own proofing record. Reserve shared credentials for non-human workloads that have a named owner.

Proofing that differs by team

When the help desk, a regional office and a contractor onboarding team each verify identity in their own way, the organization cannot show a consistent standard. One team may accept a manager's email, another may check a government-issued photo ID. Write a single proofing procedure that sets the evidence required for each context of interaction, including what counts as acceptable government-issued identification, and require every team to record which check was performed.

No link between HR records and directory accounts

If accounts are created by hand in the directory, nothing ties them to the verified person in the HR system. Assessors ask how an account traces back to a proofing event, and the answer is often a ticket that no longer exists. Establish an authoritative source for hires, and generate directory accounts from it. Sync changes and terminations automatically, so the directory reflects the same person the HR file describes.

Unrecorded exceptions to proofing

Executives, urgent contractors and emergency hires often receive accounts before proofing finishes, and the exception is never written down. Later no one can say who approved it or when verification was completed. Create a documented exception path with a named approver, an expiry date and a follow-up task that closes the proofing gap. Review open exceptions on a fixed schedule and list them in the evidence pack.

Stale accounts after role changes

Proofing establishes who someone is at enrollment, but accounts often keep the access granted for an earlier role. A person who moves departments or leaves a contract may still hold the credentials they were issued when first proofed. Tie account lifecycle events to HR changes, remove access that no longer matches the role, and sample accounts during review to confirm each still traces to a current, verified person.

Directory sync without a deprovisioning check

Many teams automate account creation but never test removal. Applications then keep users that the directory has already disabled, or remain unaware of departures. In an open-source identity stack such as authentik, the SCIM provider can push user and group changes and deprovision users from target applications, but teams should confirm that this behavior works for each connected application. Test creation, change and deletion for every target before relying on it as evidence.

Identity proofing questions buyers ask

How much effort does it take to meet PR.AA-02 identity proofing?

The effort depends mostly on how many identity populations you have and how many systems issue credentials to them. A single workforce directory with one enrollment process is far smaller than a setup that covers employees, contractors, customers and service accounts, each with its own onboarding path. Effort rises when proofing is done in person, when it relies on government-issued documents checked by staff, or when legacy applications still create accounts outside the central directory. Ask any partner to break the work into enrollment flows, the systems each flow touches, and the evidence each flow produces. Those three lists give you a defensible basis for comparing quotes.

How long does it take to get identity proofing evidence ready?

Evidence timing depends on whether your enrollment process already writes records that an assessor can read. If proofing steps are documented, applied consistently and logged, the work is mostly collection and review. If proofing happens informally, such as a manager vouching for a new hire in a chat message, the work includes designing the process, rolling it out and then waiting long enough to show it operating over real onboardings. Assessors generally want to see the process working over time, not only on the day it was introduced. Confirm with your assessor or certification body which evidence period they expect before you set a schedule.

What does identity proofing need from HR and IT?

HR owns the events that start proofing: offers accepted, contractors engaged, and roles changed or ended. IT owns the directory, the identity provider and the provisioning links that create, update and remove accounts. Practical needs include a documented list of the documents or checks accepted at enrollment, a named owner who approves exceptions, and a feed from the HR system into the identity store so that no account exists without a recorded proofing step. Both teams also need to agree who keeps the records and how long they are retained. Gaps usually appear at the handoff between the two, so map that handoff before anything else.

Can we meet PR.AA-02 with our own team?

Yes, many organizations do this in-house, provided someone owns the enrollment process end to end and can produce records on request. The work is mainly process design, configuration of the identity platform, and evidence collection. A team that already runs an identity platform and an HR integration has most of the skills needed. What in-house teams often lack is independent review of the design before an assessor sees it, and time to run the process while the evidence builds up. Be honest with yourselves about whether those two gaps can be closed internally.

What does an implementation partner do for identity proofing, and what does it not do?

DeployOpen plans, implements and documents self-hosted open-source identity systems in your own infrastructure. For PR.AA-02 that can include configuring the identity platform, connecting it to your HR source, setting up provisioning, and writing the enrollment procedure and evidence records so your team can run them. Under a fixed written scope, deliverables and timelines are agreed before work starts. DeployOpen does not own your controls, decide your proofing standard on your behalf, or issue audit reports. Only an independent auditor, assessor or certification body issues assessments or certificates, and NIST does not certify compliance with the CSF.

Does NIST certify that we comply with PR.AA-02?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. You can show alignment with PR.AA-02 by documenting your practice and providing evidence, and an independent assessor can review that evidence. Some customers or regulators may ask for a third-party assessment, but any such report comes from the assessor, not from NIST. Ask any vendor who claims a NIST certification to show you the issuing body and the scope of the claim.

Which open-source tools can produce identity proofing evidence?

Directory and provisioning tools can produce much of the evidence that proofing is linked to a single account per person. authentik's SCIM provider, for example, pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access. FreeIPA, under GPL-3.0-or-later, uses 389 Directory Server as a multi-master LDAPv3 directory that stores users and groups with centralized access control. Neither tool performs document checks on its own. Confirm with each vendor which proofing steps you must run outside the platform and how to record them.

How DeployOpen approaches PR.AA-02 engagements

PR.AA-02 asks an organization to verify identities and bind them to credentials in a way that fits each interaction. DeployOpen's role is to scope the enrollment paths in writing, build the self-hosted identity platform inside the client's own environment, and prepare the controls and evidence an independent assessor will review. The organization owns its controls, and only an independent auditor or certification body issues reports or certificates.

Written scope of enrollment paths

Before work starts, the engagement defines every path by which a person, contractor or service account receives an identity: employee onboarding, customer registration, partner access and privileged administrator accounts. For each path the scope records what proof is required, who performs the check, and which credential is issued. Clients should confirm that the scope lists the paths that exist in practice, including manual exceptions, so the assessor can test what the organization actually does rather than what the design document says.

Self-hosted identity platform build

DeployOpen plans and deploys open-source identity platforms inside the client's cloud accounts, data centers or air-gapped networks. Identity proofing depends on where the source records live, so the build decides which directory holds the verified person record and which system issues the login credential. Clients should ask which directory and identity provider will be used, how identity data is kept inside their boundary, and who holds administrative keys.

Single credential per person

PR.AA-02 covers issuing one credential to each person without sharing. In practice this means a unique identifier per user in the directory, controls that stop duplicate accounts, and a documented rule for handling shared or generic accounts. DeployOpen configures these rules and tests them against the enrollment scope. Clients should check how duplicate identities are detected when the same person returns under a new name or through a second enrollment path.

Integration with proofing workflows

Verification of government-issued identification is often performed by a separate service, a registration desk or an HR team. DeployOpen integrates the outcome of that check with the identity platform so that an account is created only after the proofing step is recorded. The integration design must show who approved each identity and when. Clients should confirm which system is the authoritative record of the proofing result and how that record is protected from edits.

Evidence prepared for assessors

DeployOpen prepares the evidence an independent assessor would request for PR.AA-02, such as enrollment procedures, sample proofing records, directory configuration exports and access logs showing account creation events. Evidence is organized by enrollment path so an assessor can sample each one. Clients should ask for a written list of evidence items, retention periods set by their own policy, and an explanation of which items they must generate themselves.

Roles in an independent assessment

The client owns its controls and decides whether PR.AA-02 is met. DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications. Any independent assessor, auditor or certification body reviews the work separately and forms its own conclusion. Clients should confirm, in the written agreement, that the deliverables are preparation materials and that the assessor is selected and paid by the organization.