PR.AA-01 Identity and credential management: requirements and evidence

What PR.AA-01 requires and why identity lifecycle is hard

If you are preparing a CSF 2.0 assessment or answering a customer questionnaire, PR.AA-01 asks your organization to manage identities and credentials for authorized users, services and hardware. In practice that means every identity has a known owner, every credential is issued through an approved request, and every certificate, token, key or device identifier can be traced and revoked. NIST's Implementation Examples describe four activities: tracking and fulfilling access requests with owner approval, issuing, managing and revoking certificates, tokens, keys and other credentials, giving each device a unique identifier, and physically labeling authorized hardware. PR.AA-01 takes over the CSF 1.1 identifier PR.AC-1 under a new number, so older evidence mapped to PR.AC-1 should be re-indexed rather than discarded.

The hard part is the lifecycle, not the initial setup. Orphaned accounts appear when someone changes role or leaves and nobody tells the system that owns the access. Shared credentials appear when a service account or break-glass login is used by several people with no record of who did what. Unmanaged keys and certificates appear when they are issued by an engineer for a pipeline and never entered into an inventory, so they expire without warning or stay valid long after the system is retired. Closing these gaps requires HR to signal joiners, movers and leavers, IT to own the directory and access approvals, and engineering to register service identities and key material. Confirm with each team who owns each step before you write the procedure, because an assessor will ask for the handoff records, not only the policy.

A useful first check is to pull a list of accounts, service identities and active certificates or keys from each system of record and compare it with your HR roster and asset inventory. Anything that cannot be matched to a named owner is a finding waiting to happen. Ask your identity or platform team to confirm which identity sources feed your directory, whether service accounts have documented owners, and how long a revoked credential remains usable. Those answers will shape the evidence you can produce for this Subcategory.

Which identities, systems and teams fall under PR.AA-01

PR.AA-01 applies to every identity and credential that can reach your systems, not only employee logins. The cards below separate the identity types, hardware and decisions that change how much work the subcategory creates, so you can agree the boundary with your assessor before evidence collection starts.

Employee and contractor accounts

Workforce accounts are the most visible identities, but contractors and temporary staff often sit outside the HR system that drives joiner, mover and leaver processes. PR.AA-01 expects access requests to be tracked and fulfilled with owner approval, so check whether contractor accounts follow the same request path. Confirm which system creates each account and which one removes it. Contractor accounts without an HR-driven end date are a common gap.

Service accounts and workload identities

Service accounts run scheduled jobs, integrations and backend processes that no person logs into interactively. Each one needs an owner, a documented purpose and a credential lifecycle. Inventory them from the systems that run them, not only from the directory, because many are created inside applications and databases. Confirm who approves their creation and how their credentials rotate or get revoked.

API credentials, tokens and keys

API keys, OAuth tokens, signing keys and encryption keys all fall under the issuing, managing and revoking work described for credentials. Their owners are often developers rather than IT, so they can be missed in scope. Ask engineering for a register of issued tokens and key stores, and confirm where secrets are kept and who can read them. Include keys held by cloud providers and build pipelines.

Certificates and their issuing authorities

Certificates bind identities to systems and services, so each one needs an owner and an expiry plan. Scope covers certificates for web services, internal services, devices and code signing, plus the internal certificate authorities that issue them. Confirm whether certificates are tracked in a central inventory and how renewal and revocation are recorded. Certificates from public authorities purchased outside IT are frequently untracked.

Hardware, endpoints and network devices

PR.AA-01 covers devices as well as people, including unique device identifiers and physical labeling of authorized hardware. Network devices, servers, laptops and mobile devices should each have a recorded identifier and a traceable owner. Reconcile the device inventory with the directory and the network registry, because devices that connect without enrollment are where scope drifts. Confirm how labels are applied and checked.

Shared administrator and SaaS identities

Two scoping choices change the work most. Shared administrator accounts make it hard to attribute actions to a person, so decide whether they are in scope as individual accountable identities or as exceptions with compensating controls. Third-party SaaS identities are in scope when your organization creates or governs them. Confirm whether each SaaS tenant is inside the boundary and whether its user lists come from your authoritative source.

Authoritative HR and IT sources

Scope depends on which systems are the source of truth for identities. An HR system usually defines employees and contractors, while a directory such as FreeIPA or an identity provider such as Keycloak may hold the operative accounts. Document which system creates, changes and removes each identity type, and where conflicts are resolved. Assessors commonly test whether accounts trace back to an approved request and an authoritative record.

How an assessor tests identity and credential management

This table walks through the four PR.AA-01 Implementation Examples and shows, for each, how an assessor typically samples the environment, which evidence they ask for and where programs most often fail. Read it as a checklist of what to prepare before fieldwork begins. The main takeaway is that assessors test the process trail behind each account or device, not only the current state of the directory.

Implementation example	How the assessor tests it	Evidence requested	Common findings
Access requests with owner approval	Samples recent joiner, mover and access grant tickets, then traces each grant back to a named resource owner and checks that approval preceded provisioning.	Request tickets, approval records with timestamps, owner register for each system, provisioning logs.	Grants made without a recorded approval, or approvals given by someone who does not own the resource.
Issuing, managing and revoking credentials	Reviews the credential lifecycle for people, service accounts, tokens and keys, and tests whether revocation happens when access ends or a credential is suspected compromised.	Credential inventory, issuance and rotation procedures, revocation tickets, directory extracts showing disabled accounts.	Stale accounts for leavers or contractors, shared credentials, and expired certificates or keys still trusted by systems.
Undocumented service credentials	Compares the service account and API key inventory against application configurations and secrets stores to find credentials nobody has recorded.	Service account register with owner and purpose, secrets manager configuration, rotation history.	Credentials embedded in scripts or configuration files, and service accounts with no named owner.
Unique device identifiers	Checks that each managed device or host can be distinguished in the directory and asset inventory, and that duplicate or generic identifiers are not used to authorize access.	Device inventory export, directory host objects, enrollment records, sample matching between asset and identity records.	Cloned or generic hostnames, devices enrolled twice, and identifiers that cannot be traced to an asset owner.
Physical labeling of authorized hardware	Walks a sample of hardware in data centers or offices and compares labels and serial numbers against the authorized hardware list.	Hardware register with serial numbers, labeling procedure, site walk notes or photographs.	Unlabeled or unregistered equipment, and labels that no longer match the inventory after replacement.
Directory and identity provider configuration	Reviews how the central directory and single sign-on service are configured to create, change and remove accounts, and whether applications take their identities from that source.	Architecture diagram, provisioning configuration, sync logs, list of connected applications.	Applications with local accounts that bypass the central directory, and sync jobs that silently fail.
Evidence of periodic review	Tests whether accounts and credentials are reviewed on a defined schedule and whether reviewers act on the results.	Review campaign records, reviewer sign-offs, removal actions taken after review.	Reviews that approve everything without change, or findings that stay open for long periods.
Informative reference pointers	Assessors may map their tests to the SP 800-53 Rev. 5.2.0 and ISO/IEC 27001:2022 references listed for PR.AA-01. Confirm with the assessor which framework their report will use.	Confirm the framework and control set the assessor will report against before collecting evidence.	Evidence gathered for one framework may not cover the wording another assessor expects.

How to implement PR.AA-01 in sequence

This sequence moves an organization from knowing which identities and credentials exist to proving that each one is issued, approved, rotated, revoked and tied to a known device. Each step produces a record that an assessor can sample.

Inventory identity sources and credential types
Start by listing every place identities are created or stored, such as the workforce directory, application local accounts, service accounts, API clients, certificate authorities, hardware tokens and device enrollment systems. For each source, record the credential types it issues (passwords, certificates, tokens, keys, device identifiers) and the system owner. The step is complete when the identity owner signs off on an inventory that covers every source the team knows about, and the gaps are logged as open items with an assigned owner.
Define the access request and owner approval workflow
Document how a person or system requests access, who must approve it (normally the resource owner, not the requester), what evidence the approver checks, and how fulfillment is recorded. Decide where requests are tracked, such as a ticketing system or an identity governance workflow, and whether emergency requests follow a separate path. The output is a written workflow and a sample request record showing requester, approver, decision time and the grant made. Confirm with your own environment which tool will hold the record, because the workflow only counts as evidence if it is retained.
Provision identities through a single authoritative source
Connect the identity sources from the inventory to one authoritative directory so that accounts are created, changed and removed from one place. Open-source options such as FreeIPA (389 Directory Server as its LDAPv3 store) or Keycloak can hold users and groups, while an SCIM provider such as the authentik SCIM provider can push changes to downstream applications. Test one joiner, mover and leaver case end to end. The step closes when a test account created in the source appears in the target application and disappears when access is removed, and the test result is saved.
Set issuance, rotation and revocation rules for credentials
Write the rules for each credential type: who may issue a certificate, token or key, the approved algorithms and lifetimes your policy sets, how keys are rotated, and the exact steps for revoking a credential when a person leaves, a device is lost or a key may be exposed. Assign an owner for each rule and decide where key material is stored. The output is a credential standard and a revocation runbook. Test the runbook once against a non-production credential and keep the timestamped result, since an assessor will ask for proof that revocation works, not only that a procedure exists.
Assign unique identifiers to every device
Give each device that connects to the environment a unique identifier that is recorded in the asset inventory and linked to its owner. This covers managed endpoints, servers, network appliances and IoT or operational technology where feasible. Where devices authenticate, bind the identifier to a certificate or enrollment record so the device can be traced and disabled. The step is complete when a reconciliation between the device inventory and the identity system shows no unidentified devices in scope, and exceptions are documented with a compensating control and an approver.
Label authorized hardware physically
Apply physical labels to authorized hardware, such as asset tags that match the device identifier in the inventory, and define what the label must show (asset number, owner, classification if needed). Brief the staff who receive, move or dispose of equipment so that unlabeled or unrecognized hardware is reported. Confirm with facilities or the data center operator how labels are applied in leased or shared spaces. The output is a labeling standard and a sample walk-through record that matches tags to the inventory.
Reconcile and retain evidence for assessment
Run a periodic reconciliation that compares the identity inventory, the credential records, the device identifiers and the physical labels against each other, then records the discrepancies and how each was closed. Keep the approved requests, provisioning test results, revocation test records and reconciliation reports in one evidence location with a stated retention period set by your own policy. The sequence is complete when an internal reviewer can pick any credential and trace it from request and approval through issuance to revocation without asking the system owner for missing records.

How the identity lifecycle connects joiners, movers and leavers

The core decision in this part of PR.AA-01 is which system is the authoritative source for identities. Every joiner, mover and leaver event should originate there, not in the applications that consume identities. A request for access, approved by the resource owner as the Implementation Examples describe, creates or changes an identity in the source. From that point, a directory holds the identity and its group memberships, an SSO broker decides how users sign in to each application, and a provisioning connector pushes the account and its entitlements into each target system. When these three layers are designed together, a change made once in the source is reflected everywhere the person has access. When they are designed separately, each application becomes its own small source of truth, and the copies drift apart.

Movers are where drift usually starts. When someone changes role, the new group memberships should be added and the old ones removed in the same operation, so the person does not accumulate access from every position they have held. Leavers are where the most serious gaps appear. Deprovisioning fails when an application keeps a local account that no connector manages, when a service account outlives the person who owned it, or when a connector runs but an application was never added to its scope. Confirm for each target application whether removal happens through a connector, through the SSO broker alone, or manually, and whether a periodic reconciliation would catch accounts that exist without a matching source record. The authentik SCIM provider, for example, runs a full sync every hour and deprovisions users when they lose access, but a reconciliation report still needs to be reviewed and retained as evidence.

The evidence an assessor will ask for follows from this design: the source records with timestamps, the provisioning logs showing creations, changes and removals, and a list of accounts in each target application compared against the source. Ask your implementation partner and internal team to agree, in writing, which system owns each attribute, who may approve a request, and how long removal may take after a termination. Those answers belong in the access procedure before any connector is configured, because a connector only automates the rules it is given.

Choosing a self-hosted directory, broker or provisioning approach

FreeIPA pairs the 389 Directory Server with identity management features, giving you one place to store users, groups, hosts and other network objects. It fits organizations that run Linux hosts and need a single source of truth for accounts, host identities and access rules, along with delegated administration so that help desk staff or application owners manage only the objects they should.

Unique identities: users, groups and hosts are stored as directory objects, which supports the unique identifiers that PR.AA-01 expects.
Delegated administration: you can grant narrow administrative rights through the web UI or command line tools instead of sharing a single administrator account.
Multi-master replication: the 389 Directory Server runs as a multi-master LDAPv3 directory, so confirm the replication topology you need across sites.
Licensing: FreeIPA is licensed under GPL-3.0-or-later. Confirm with the project how that license applies to your deployment and any modifications you make.
Limits: a directory does not provide single sign-on by itself, so plan for a separate broker if applications need it.

Confirm supported operating systems, replication limits and upgrade paths with the FreeIPA project before you commit to a design.

Evidence that shows PR.AA-01 is working

PR.AA-01 is met when the organization can show who holds each identity and credential, who approved it, and when it was retired. The artifacts below connect those answers, and each one goes stale unless someone reconciles it on a schedule rather than only before an assessment.

Approved access request records

These are the tickets or workflow entries that show each account, group membership or credential was requested, approved by the resource owner, and fulfilled. Check that every sampled grant has an approver who owns the resource, not the requester, and that the approval predates the grant timestamp. Reconcile a sample of new accounts against approved requests each month, and flag any account created outside the workflow.

Identity inventory with owners

This is the register of every human, service and hardware identity, with a named owner, purpose and status for each. An assessor tests whether the inventory is complete by comparing it against directory exports. Schedule a recurring reconciliation of directory accounts against HR records for employees and contractors, and against system owner lists for service accounts, so leavers and orphaned accounts surface quickly.

Credential issuance and revocation logs

These logs record when passwords, tokens, one-time codes and other authenticators were issued, reset and revoked, and by which process or administrator. The revocation entries matter most, because they show that access ends when a role ends. Confirm that logs are retained long enough to cover your audit period and that someone reviews revocation timing against termination dates each quarter.

Certificate and key registers

A register lists each certificate and cryptographic key with its owner, issuing authority, expiry date, storage location and rotation history. Expired or unowned certificates are a common finding because nothing alerts anyone before an outage. Review the register against live certificate discovery on a fixed schedule, and confirm that revoked or replaced keys are removed from every system that trusted them.

Device identifier records

These records show that each managed device or workload has a unique identifier, such as a hostname, asset tag, serial number or certificate subject, and that duplicates are not allowed to join the network. Compare the identifier list against endpoint management and network access logs to find devices that connect under identifiers no one registered. Run this comparison whenever devices are imaged, replaced or added in bulk.

Hardware labeling records

Labeling records tie physical equipment to its asset entry, usually through a tag or engraved identifier that matches the inventory. They let staff confirm that a device found on a rack or in a shipment is authorized. Sample physical hardware against the labeling log during site walkthroughs or asset counts, and record exceptions with a decision on whether the device stays in service.

What meeting PR.AA-01 costs in money and effort

This table breaks down the cost components of managing identities and credentials for PR.AA-01, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote and to see where self-hosted open source reduces license spend without removing integration and process effort.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to ask for in a quote
Tooling and licenses	Software vendor, or no license fee for self-hosted open-source components	Recurring if commercial licenses or hosted support apply; none for the open-source code itself	Ask the quote to separate license fees from support subscriptions, and to state which components are open source and which are paid add-ons.
Infrastructure to host the identity stack	Client cloud or data center costs, paid to the infrastructure provider	Recurring	Driven by high availability design, number of identities and environments. Ask for a list of hosts, redundancy assumptions and who operates them.
Connector and source integration	Implementation partner engineering time, with client staff for source system access	One-time, with recurring changes when sources change	Each HR system, directory or application connected to the identity source adds effort. Ask for an itemized list of sources and the connector method for each.
Process design and approval workflow	Client owners and approvers, plus partner time to configure request workflows	One-time design, recurring approvals	Depends on how many access request types exist and how owner approval is defined. Ask for the workflow diagram and the approver roles named in the scope.
Certificate, token and key lifecycle setup	Partner engineering and client security staff	One-time setup, recurring rotation and revocation	Scales with the number of certificates, keys and service credentials. Ask how issuance, renewal and revocation are handled and who owns the key material.
Evidence collection and upkeep	Client compliance and operations staff, sometimes with partner support	Recurring	Frequency of access reviews, log retention and the number of evidence types drive effort. Ask for a list of evidence artifacts and how they are generated.
External testing or review	Independent testing firm or security testers, paid by the client	Recurring at the frequency the client sets	Scope of identity testing, such as credential handling and account takeover paths, sets the price. Ask for a written test scope before work starts.
Auditor sampling and assessment	Independent auditor or assessor, paid by the client	Recurring per assessment cycle	Sample sizes and the number of identity processes tested determine effort. Ask the auditor to confirm the sampling approach before fieldwork.
Ongoing support and upgrades	Implementation partner under a retainer, or internal platform team	Recurring	Upgrade frequency, patch windows and the number of supported environments drive cost. Ask whether support is fixed-scope or retainer-based and what is excluded.

Questions buyers ask about PR.AA-01 cost, effort and outsourcing

Can we meet PR.AA-01 in-house without an outside partner?

Yes, in principle. NIST CSF 2.0 is voluntary, and the organization owns its own controls, so internal staff can design and run identity and credential processes for users, services and hardware. The work depends on whether your team already runs an access request workflow, certificate and key lifecycle management, unique device identifiers and asset labeling. Gaps usually appear in the evidence: owner approvals for access requests, records of certificate and token revocation, and an inventory showing each device's identifier. Ask whether your staff can produce that evidence on demand, not only whether the processes exist. An outside partner is most useful when the team lacks time or experience with self-hosted identity platforms.

How much effort does PR.AA-01 need from HR and IT?

HR and IT share the work. HR supplies joiner, mover and leaver events that trigger access requests and removals, and must confirm who approves access for each role. IT owns the directory, the credential and key lifecycle, device identifiers and hardware labeling. The effort depends on how many systems hold identities, how many services and devices need credentials, and whether joiner and leaver processes are already automated. Ask any provider to break the effort down by HR task and IT task in the written scope, so you can see which hours fall to your staff and which fall to the partner.

Will an assessor accept our own self-assessment evidence for PR.AA-01?

That depends on the assessor and the framework that asks for the evidence. NIST does not offer certifications or endorsements of CSF implementations, so no body certifies PR.AA-01 alone. If a customer or regulator asks for a CSF alignment review, the organization can present its own records, such as approval tickets, certificate revocation logs and device inventories. An independent assessor decides how much weight to give internal evidence. Ask the assessor before fieldwork which records they will sample and whether they accept internally produced reports.

How long does PR.AA-01 work take to complete?

Duration is set in the written scope, not by a general rule. The timeline depends on how many identity sources, applications, certificate authorities and device types are in scope, and on how much of the access request and revocation process is already documented. A fixed-scope engagement agrees deliverables and timelines in writing before work starts, so ask for a dated plan with milestones for design, build, evidence collection and handover. Do not accept a duration that is not tied to a defined scope.

Does PR.AA-01 require a certificate, and who issues it?

No. PR.AA-01 is a Subcategory of the CSF 2.0 Core, and NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services. Nothing in the CSF itself produces a certificate for this outcome. Some customers or contracts ask for evidence of alignment instead. Where a formal report is needed, an independent auditor or assessor issues it against whichever standard the contract names. DeployOpen prepares systems and evidence but does not issue audit reports or certifications.

What must our organization supply to an implementation partner?

Give the partner a clear picture of your identity landscape before scoping starts. Typical inputs include a list of identity sources and the applications that rely on them, the current process for access requests and approvals, the certificate authorities and key stores in use, a device inventory with identifier conventions, and the policy owners who approve access. You should also name a technical owner and an approver for each area, and provide access to the environments where the work will run. Request in the quote that the partner list every input it expects, so gaps are found before the schedule is fixed.

What recurring costs follow the one-time PR.AA-01 work?

Some costs repeat after the initial build. Staff time continues for access reviews, approvals, certificate renewals, key rotation and labeling of new hardware. Platform upkeep, such as patching the directory, single sign-on and certificate tooling, also recurs. Ask whether a support retainer covers upgrades and continuous checks, and what the quote excludes. Costs for licenses, hosting and backups depend on the platforms you choose, so confirm them with each vendor in your own environment.

How DeployOpen scopes and prepares PR.AA-01 evidence

DeployOpen works on PR.AA-01 identity and credential management as implementation and evidence preparation inside your own infrastructure. We set up the identity platforms, lifecycle workflows and credential records that produce the evidence, then hand over documentation. Your organization owns the control, and an independent auditor or assessor decides whether the evidence meets the requirement.

How we scope

Engagements are fixed-scope, with the identity sources, applications and hardware classes in writing before work starts.
The written scope lists which identities, service accounts, certificates, tokens and keys fall under PR.AA-01.
Scope also names the systems that will hold access request records, owner approvals and revocation logs.

How we build

We deploy the chosen open-source identity platform in your cloud accounts, data centers or air-gapped network.
We configure provisioning and deprovisioning so access changes flow to target applications, then test revocation end to end.
We set up unique device identifiers and credential issuance records, and check that logs capture each issuance and revocation.

How we hand over

You receive configuration documentation, runbooks for access requests, and a mapping of each deliverable to the PR.AA-01 Implementation Examples.
Evidence exports are described so your team and assessor know where each record lives and how to retrieve it.
Your staff are walked through administration tasks so the control keeps running after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover platform upgrades, credential rotation reviews and periodic checks that revocation still works.
Any change to scope after signing is agreed in writing before work on it begins.

PR.AA-01 Identity and credential management