What PR.AA-03 authentication requires in NIST CSF 2.0
If your CSF 2.0 gap analysis or a customer questionnaire asks about PR.AA-03, the short answer is this: the outcome requires that users, services and hardware are authenticated before they receive access. NIST describes four Implementation Examples under this Subcategory, and an assessor will expect to see each one addressed in your current state or explicitly planned in your target state. The four are requiring multifactor authentication, enforcing minimum strength for passwords, PINs and similar authenticators, reauthenticating periodically based on risk (as in zero trust architectures), and ensuring emergency access to accounts essential for safety. In plain terms, you need to know which logins are protected by a second factor, which authenticators are too weak to accept, when a session should be challenged again, and how a person can still reach a critical system when the normal login path fails. PR.AA-03 is not new in substance. It takes over CSF 1.1 PR.AC-7 under a new identifier and absorbs part or all of CSF 1.1 PR.AC-3, according to NIST's transition spreadsheet. If your organization already mapped PR.AC-7 in a 1.1 assessment, carry that evidence forward, but check the transition changes for the PR.AC-3 portion, because remote access controls that were once evaluated under that identifier now sit under this Subcategory as well. Confirm the exact mapping against NIST's published transition file rather than relying on memory or on a third-party crosswalk.
The hard part is rarely the policy. It is the inventory. Legacy applications often accept only a username and password, or they sit behind a single sign-on gateway that is not enforced for direct API calls. Shared accounts used by operations teams, vendors or kiosks make it impossible to attribute a second factor to one person. Service identities and machine-to-machine credentials do not prompt for a code at all, so reauthentication and emergency access need separate design. Start by listing every login path, including admin consoles and break-glass accounts, and record for each one the authenticator type, whether a second factor applies, and who can reach it during an outage. That list becomes the evidence base for every Implementation Example. If you run an open-source identity layer, such as authentik with its authenticator validation stage, FreeIPA with its TOTP and HOTP support, Keycloak for single sign-on, or Zitadel as a central broker, confirm in your own environment which factors are enforced at each application. Brokering through a central identity provider does not by itself prove that every application requires the same factor. Ask the vendor or your integrator to demonstrate enforcement, and retain the configuration and test results as evidence.
Which accounts, services and devices fall under PR.AA-03
PR.AA-03 asks that users, services and hardware are authenticated, so its scope reaches every identity that can reach your systems. The decisions below determine how much of your estate needs stronger authentication, and which populations need different controls.
Workforce accounts
Employee, contractor and temporary staff accounts that sign in to email, collaboration tools, business applications and endpoints. This population usually defines the first wave of multifactor authentication. Confirm which workforce identities sit in your directory, which accounts are still local to an application, and whether contractors are provisioned outside the normal joiner process. Every account that offers a second factor should have one enabled, and the exceptions should be documented.
Customer accounts
Accounts held by customers, members or citizens who use your public or partner-facing services. Scope depends on what the account can reach: viewing a profile carries different risk than initiating a payment or changing contact details. Decide which flows require a second factor, how step-up authentication applies to sensitive actions, and how account recovery is handled. Recovery paths are often the weakest point in an otherwise strong login.
Privileged and administrative accounts
Accounts that can change configuration, grant access, read protected data or disable security controls, including domain administrators, cloud tenant owners and database administrators. These accounts carry the highest impact if compromised, so they are usually the first population to receive phishing-resistant factors and the shortest reauthentication intervals. Check whether administrators use separate accounts for daily work, and whether every privileged path uses the same authentication strength as the console.
Non-human service accounts
Service accounts, API clients, automation pipelines and workloads that authenticate without a person present. Multifactor authentication does not fit these identities directly, so PR.AA-03 work here means controlling how their secrets are issued, stored, rotated and restricted. Confirm which services use shared passwords, long-lived tokens or static keys, and whether each has a named owner. Record the strength requirement you apply to them, even where a second factor is not possible.
Hardware and devices that authenticate
Laptops, mobile devices, hardware security keys, network equipment, industrial controllers and other devices that present a credential to join or reach a network. Scope includes both the device identity and any hardware token used by a person. Confirm which devices can be enrolled and tied to a user, which hardware keys are issued, and how lost or retired devices are removed from trust. Devices that cannot run modern authenticators may need compensating controls that you document as such.
Legacy applications and break-glass accounts
Two scoping decisions change the work most. Legacy applications that cannot accept federated sign-in or a second factor may stay in scope with compensating controls, such as network restriction or a broker in front of them, or they may be retired. Break-glass accounts that provide emergency access during an outage or safety event must work when the normal identity provider is down, so they are usually excluded from routine factor enforcement. Document each exception, its owner, its monitoring and its review date, because PR.AA-03 includes emergency access to accounts essential for safety.
How authentication controls fit together across identity systems
In this pattern, users authenticate once with Keycloak rather than separately in each application, and applications trust the tokens it issues over OpenID Connect, OAuth 2.0 or SAML 2.0. That makes Keycloak the natural place to set the authentication policy for PR.AA-03, including which factors are required and how sessions are refreshed. The control still depends on each application honoring the session and not accepting its own weaker login path.
- Multifactor enforcement: Configure required second factors at the realm or authentication flow level so every application inherits the same requirement.
- Authenticator strength: Document which credential types are allowed and set the minimum your policy requires for passwords and other authenticators.
- Session and reauthentication: Set session lifetimes and idle timeouts that reflect your risk decisions, since periodic reauthentication is part of the PR.AA-03 implementation examples.
- Client configuration: Confirm each registered client uses the expected protocol and does not allow direct password grants or legacy login paths that bypass the central flow.
- Emergency access: Decide how accounts needed for safety are reached if the identity provider is unavailable, and test that path.
For each application, verify that it redirects to the central login, rejects sessions it did not receive, and enforces any local administrative access separately. Confirm these specifics against your Keycloak version and your application configuration.
In this pattern, FreeIPA holds the directory of users and adds a second factor through HOTP and TOTP tokens. Software tokens can be enrolled by QR code and hardware tokens such as YubiKeys are supported. During a migration, FreeIPA can proxy OTP checks to an existing RADIUS server, which lets teams move authentication in stages rather than all at once. The main PR.AA-03 question here is whether every login path that reaches the directory enforces the second factor.
- Token enrollment: Define who may enroll tokens, how enrollment is verified, and how lost tokens are replaced, since these steps shape the strength of the second factor.
- Supported token types: Confirm which HOTP, TOTP and hardware token types you accept and document them as the authenticator standard.
- RADIUS proxy during migration: If OTP checks are proxied to an existing RADIUS server, record that the second factor is still validated and track when the proxy is retired.
- Login paths: Check whether services that bind to LDAP or Kerberos directly apply the OTP requirement, or whether some accounts can authenticate with a password alone.
- Emergency access: Keep a documented break-glass procedure for administrators who cannot use their tokens, and log its use.
For each application that uses the directory, verify that it either delegates login to FreeIPA with the OTP step or enforces its own equivalent. Confirm token types and proxy behavior against the FreeIPA release in your environment.
In this pattern, Zitadel sits between your applications and external identity providers such as Google, Microsoft Entra ID or Okta. Users sign in at the provider they already use, over OpenID Connect, SAML 2.0 or LDAP, and applications trust only Zitadel. Authentication strength then depends partly on the external provider, which the organization does not fully control. PR.AA-03 evidence must therefore show what the broker requires and what it accepts from the upstream provider.
- Upstream factor requirements: Ask each external provider which multifactor methods it enforces for your tenant, and record the answer as part of your evidence.
- Broker policy: Define in Zitadel which identity providers are offered to which applications, so that a weaker provider cannot be used for a sensitive application.
- Trust configuration: Review the protocol and certificate settings for each external provider, including how signatures are validated.
- Reauthentication: Decide whether the broker forces a fresh upstream login for risky actions, and confirm the provider supports that request.
- Emergency access: Plan for an external provider outage, including local accounts or an alternate provider for safety-critical systems.
For each application, verify that it accepts only tokens from Zitadel and that the broker enforces the provider list you approved. Confirm which upstream factors each provider applies in your tenant, because this is outside the broker's own enforcement.
How an assessor tests PR.AA-03 authentication
This table compares the four NIST Implementation Examples for PR.AA-03 by what an assessor samples, the evidence requested and the findings that most often appear. Read each row as a test an assessor can repeat: pull the configured policy, sample accounts, then compare what the system actually enforces against what the policy says.
| Implementation Example | Evidence requested | Common findings |
|---|---|---|
| Require multifactor authentication | Exported authentication policy or flow configuration, list of enrolled second factors per sampled account, and login logs showing a second factor was checked | MFA exempted for service or administrator accounts without a documented reason, or enforced on the portal but not on legacy or API paths |
| Enforce minimum strength for passwords, PINs and similar authenticators | Password and PIN policy settings as exported from the identity platform, plus evidence of how changes were approved and when they took effect | Policy documented in a procedure but not configured in the platform, or minimum length set without checks against common or breached values |
| Reauthenticate periodically based on risk | Session lifetime and reauthentication rules, risk signals used to trigger step-up checks, and samples of step-up events in logs | Fixed session timeouts with no risk-based trigger, or risk rules defined in a document that no sampled login ever reaches |
| Ensure emergency access to accounts essential for safety | Written emergency access procedure, list of break-glass accounts with their owners, and records of when the accounts were last tested or used | Break-glass accounts without MFA or with shared credentials, no owner named, or no record that the procedure was ever exercised |
| Sampling and comparison method | Random and risk-based sample of user, service and administrator accounts, with configuration screenshots or exports for each | Assessor finds a gap between the documented policy and the exported configuration, which is usually the first finding raised |
Implementing PR.AA-03 step by step
This sequence turns PR.AA-03 from a policy statement into a working authentication baseline: every account and authenticator is known, MFA is enforced where supported, reauthentication and emergency access are defined, and each step leaves evidence an assessor can sample.
Inventory accounts and authenticators
Build a register of every account type in scope: workforce users, administrators, service accounts, API clients, network devices and hardware that authenticates. For each, record the authenticator in use (password, TOTP, WebAuthn or FIDO2 passkey, SMS, certificate, static key), who owns it, and whether the platform can enforce a second factor. Export directory and application data where possible instead of relying on memory. Done means every in-scope system appears in the register with an owner and an authenticator type, and gaps (systems with no central login or unknown authenticators) are logged as findings.
Pick the identity source of truth
Decide which directory or identity provider holds the authoritative user record and issues sign-ins for applications. Where a self-hosted platform is in scope, options include a central identity provider such as Keycloak or authentik, or a directory such as FreeIPA, with external identity providers brokered through it. Document the decision, the systems that trust it, and the systems that still keep local accounts. Done means a diagram and a list of applications showing which ones authenticate through the chosen source, with exceptions approved in writing.
Enforce MFA on every account that offers it
Turn on a second factor for each account that supports one, starting with administrators, remote access, email and finance or customer data systems. Configure the authenticator validation or OTP stage so enrolled factors are checked at login, and set enrollment rules and recovery codes under the control of the identity team. Where an application cannot enforce MFA, record the compensating control (such as network restriction or a gateway that performs the check) and the owner who accepted it. Done means a report of enforcement status per account, with exceptions tied to an accepted risk.
Set minimum authenticator strength
Write a standard that states the minimum for each authenticator class, covering passwords, PINs and other memorized secrets, and the factor types allowed for each population. Configure the platform to reject weak choices where it can, and remove factors the standard no longer allows, such as SMS for high-risk accounts if your risk assessment rules it out. Confirm recovery paths do not undercut the rule. Done means a signed standard, a configuration export showing the enforced settings, and a sample test login for each rule.
Define risk-based reauthentication triggers
Specify the events that require a fresh authentication: privileged actions, access from a new device or unusual location, sessions older than a set limit, changes to security settings, and access to sensitive data. Thresholds should come from your own risk assessment, not a default. Configure session lifetimes and step-up prompts in the identity platform and in high-value applications. Done means a trigger table mapped to the systems that implement it, and test records showing a reauthentication prompt fires for each trigger.
Document and test break-glass access
Create emergency accounts for cases where the normal identity provider is unavailable and access is needed for safety or critical operations. Store credentials under dual control, use strong authenticators, restrict use to named scenarios, and alert on every login. Write a runbook covering who may invoke it, how it is logged, how credentials are rotated afterward, and how the account is disabled when no longer needed. Run a test at a scheduled interval you set, and record the outcome. Done means an approved runbook and a dated test record showing the account worked and the alert fired.
Collect and retain PR.AA-03 evidence
Gather the artifacts an assessor will sample: the authenticator register, identity source diagram, MFA enforcement report, authenticator standard, configuration exports, reauthentication trigger table, break-glass runbook and test records, and sign-in logs showing enforced factors. Assign an owner to refresh each one on a cadence you define and store them in a controlled repository. Confirm which evidence an independent assessor will need, since DeployOpen prepares evidence but only the assessor judges it. Done means an evidence index that maps each artifact to the PR.AA-03 outcome and its owner.
Evidence that passes a PR.AA-03 review
An assessor testing PR.AA-03 looks for proof that users, services and hardware are authenticated as designed, not just a policy that says so. The cards below cover the artifacts that show enrollment, policy, live behavior, reauthentication, emergency access and tested results, and how to refresh each one between assessments.
MFA enrollment reports
A report listing every account, its enrolled second factors (TOTP apps, WebAuthn or FIDO2 passkeys, hardware tokens, recovery codes) and the enrollment date. It shows coverage, which is the first thing an assessor checks against the requirement to use multifactor authentication where it is available. Check for accounts with no second factor and document an exception for each one. Schedule the export monthly from the identity provider and keep the dated copies in a read-only location.
Authentication policy exports
Configuration exports of password, PIN and authenticator strength rules, lockout settings and which flows require which factors. Assessors compare these settings with your written standard for minimum authenticator strength. Export the configuration after every change, store it in version control, and tie each change to an approved ticket so the history is traceable.
Sample login logs with second factor checks
Authentication logs that show the second factor being validated during sign-in, including the factor type and the result. Random samples from several applications and user groups are stronger evidence than a single screenshot. Confirm that logs record factor validation events, not only password success. Set retention so that a full assessment period is covered, and confirm the retention setting with your log platform.
Reauthentication policy settings
The settings that control how often and under what conditions users must authenticate again, such as session lifetimes, step-up triggers for sensitive actions, and risk signals that force reauthentication. This is the evidence for risk-based reauthentication. Keep a record of which policy applies to which application, and review the settings with the owner of each application at a fixed interval.
Break-glass account records
Records for emergency accounts that keep access to systems essential for safety when normal authentication fails. Include who holds them, where credentials are stored, how use is approved and logged, and the date of the last test. Assessors look for proof that these accounts are protected by strong controls and reviewed after each use. Update the list whenever an owner leaves or a system changes, and rotate the stored credentials on a documented schedule.
Access test results
Dated results from tests that try to sign in without a second factor, reuse expired or weak authenticators, or reach protected applications through a service account. Test results show whether the configuration works in practice, not only on paper. Run the same test set after each identity platform upgrade or policy change, and file the results with the change ticket that triggered them.
What meeting PR.AA-03 costs in money and effort
PR.AA-03 has no fee schedule, and its cost depends almost entirely on how many systems must enforce multifactor authentication and how many user accounts must enroll. NIST CSF 2.0 is a voluntary framework with no certification program, so there is no official price for meeting the outcome. The organization pays for four things: authenticator hardware or software, engineering time to move applications onto a shared login flow, enrollment support for users, and the upkeep of evidence. An external assessor or auditor, if you commission one, is a separate fee paid to that firm, not to NIST or to any implementation partner.
Licenses and hardware tokens are the most visible costs, but they are often not the largest. Open-source identity platforms such as authentik, Keycloak, Zitadel and FreeIPA carry no license fee for the software itself, so the recurring spend shifts to hosting, support contracts if you buy them, and staff time. Hardware security keys are a one-time purchase per user with replacement cost when lost. Engineering time is usually one-time: each application needs its login path changed to trust the central broker, and legacy systems that cannot speak OpenID Connect or SAML 2.0 may need a longer migration or a RADIUS-style bridge. Ask any quote to price these migrations separately, by application, so you can see which ones drive the total.
Recurring costs are the ones finance teams tend to miss. Enrollment help, recovery requests from users who lose a device, and emergency access procedures all continue after go-live. Evidence upkeep is also recurring: keeping exported configuration of the authenticator validation stage, proof that accounts without a second factor were blocked or flagged, and records of periodic reauthentication settings current for each review cycle. Ask any implementation partner to state which deliverables are one-time and which are retainers, and to name the evidence it will hand over at handover. Confirm with your auditor, before work starts, which evidence they will accept and how many samples they will pull, since that determines how much records work you need to budget for.
Cost components for PR.AA-03 and how to reduce them
This table lists the cost components of meeting PR.AA-03 authentication, who is paid for each, whether it is one-time or recurring, what drives it, and how to keep it down. Read it as a checklist for a quote, since most of the spend sits in enrollment, upkeep and testing rather than in software licenses.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring | Whether the authenticator platform is commercial, and per-user fees for hosted identity services or add-on second-factor providers | Self-hosted open-source platforms such as authentik (MIT), Keycloak (Apache-2.0), FreeIPA (GPL-3.0-or-later) or Zitadel (AGPL-3.0-only) remove product license fees, but confirm the license terms, including AGPL obligations for Zitadel, with counsel before deployment |
| Engineering time to configure MFA | One-time, with later changes recurring | Number of applications behind single sign-on, protocols in use (OpenID Connect, SAML 2.0, LDAP), and whether legacy apps need proxying or brokering | Put every application behind one identity provider first, and agree the authenticator policy in writing so configuration is not reworked per application |
| Policy design for minimum authenticator strength and risk-based reauthentication | One-time, with periodic review | Number of user populations, privileged roles and risk signals the organization wants to act on | Start from the four Implementation Examples for PR.AA-03 and document a small set of tiers rather than per-application rules |
| User enrollment and support | Recurring | Number of users, hardware token issuance, lost-device resets and help desk volume | Offer software authenticators and passkeys alongside hardware tokens, and set a self-service recovery path using recovery codes or verified channels |
| Emergency access accounts | One-time setup, recurring testing | Number of systems that must stay reachable during an identity outage and the procedures needed to use break-glass accounts safely | Keep the list of break-glass accounts short, store credentials under dual control, and test access on a schedule you can repeat |
| Evidence upkeep | Recurring | Frequency of configuration exports, enrollment reports, policy reviews and change records an assessor will request | Automate exports from the identity platform and keep dated configuration snapshots in version control |
| External testing | Recurring or per engagement | Scope of authentication testing, including login, MFA bypass, token handling and account recovery flows | Agree scope in writing before work starts, and reuse the prior test baseline so each cycle focuses on what changed |
| Auditor sampling and assessment support | Recurring at each assessment cycle | Sample sizes the assessor chooses, the number of systems in scope and how many evidence requests fall to the identity team | Keep evidence indexed by control, so sampling requests are answered from a single source rather than rebuilt for each audit |
Who owns PR.AA-03 and who can help
Your organization owns PR.AA-03. NIST CSF 2.0 is a voluntary framework, and the decisions about which users, services and hardware need strong authentication, which authenticator strengths are acceptable, and when reauthentication is required belong to your leadership and security function. Those decisions are business and risk choices, and they cannot be delegated to a vendor.
- Policy and risk decisions: Set the authentication policy, the minimum authenticator strength for each account class, and the risk signals that trigger reauthentication.
- Emergency access rules: Decide which accounts are essential for safety, who may use them, and how their use is approved and logged.
- Ownership of the identity provider: Name an accountable owner for the identity platform, its administrators and its configuration changes.
- Exception handling: Record and approve any account that cannot use multifactor authentication, with an end date and a compensating control.
- Review cadence: Confirm that someone internal reviews enrollment reports and authentication logs on a schedule you define.
Before engaging anyone, confirm internally who will sign the control statement and who answers assessor questions.
DeployOpen is an implementation partner. It plans, builds, configures, hardens, migrates and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For PR.AA-03, this work usually covers the identity platform and the evidence that shows its controls operate. It does not decide your policy, issue a report or certify that the control meets any standard.
- Identity platform build: Deploy and configure a self-hosted identity layer, such as Keycloak, authentik, Zitadel or FreeIPA, with the second-factor methods you approve.
- Migration: Move existing accounts, enrollments and legacy OTP or RADIUS dependencies with a documented cutover plan.
- Evidence scripts: Produce exports of enrolled factors, policy configurations and authentication logs that your team and the auditor can read.
- Documentation: Write runbooks for emergency access, factor reset and administrator recovery.
- Scope agreement: Work is typically fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ask the partner to state in writing which evidence it prepares and which decisions it leaves to you.
An independent auditor, assessor or certification body tests the control and decides whether the evidence supports the conclusion. NIST does not offer certifications or endorsements for CSF implementations or services and has no plans for a conformity assessment program, so a CSF claim is usually supported by an assessment performed by a party chosen by your organization or by a customer. Some frameworks that map to PR.AA-03, such as ISO/IEC 27001 or SOC 2, do have accredited or attest-based routes, and the auditor for those will test the same authentication controls.
- Independence line: The partner that built the system should not also write the assessor's conclusion or attest to its own work.
- Sampling: The auditor selects accounts, enrollments and emergency access events and inspects them directly.
- Evidence trail: Expect requests for policy versions, configuration exports, log extracts and approvals for exceptions.
- Scope confirmation: Agree in advance which systems, user populations and service accounts are in scope.
- Written output: Only the auditor's report, attestation or certificate counts as independent confirmation.
Confirm the assessor's accreditation or attestation route with the customer or regulator that requires the claim, since requirements differ.
Where PR.AA-03 programs usually fall short
PR.AA-03 asks whether users, services and hardware are authenticated, and assessors test that answer across every path into a system. The gaps below tend to appear where authentication was set up in one place and never checked against the rest of the estate. Each card names one gap and the check that exposes it.
MFA exempted for service and legacy apps
Teams often exclude service accounts, older applications and API paths from the second factor because enrollment breaks them. The exemption then becomes the easiest route in. Build an inventory of every login path, including direct LDAP binds, legacy protocols and internal tools, and record each exemption with an owner, a compensating control and a review date. Confirm that the identity provider policy and the application configuration agree, because a policy that says MFA is required does not help if one application accepts a password alone.
Authenticator minimums set but not enforced
A password or PIN policy written in a document is not the same as one the system applies. Check the configured minimum strength, the lockout and throttling settings, and whether the rules apply to every realm, client and directory that issues credentials. Ask for a test where a deliberately weak credential is rejected at enrollment and at change. Note that minimum strength also covers the factor types you allow, so a weak fallback method can undo a strong primary one.
Emergency accounts never tested
Break-glass accounts exist so people can reach systems needed for safety when normal sign-in fails. They commonly share one password, sit in a vault nobody has opened recently, and have never been used to log in. Record who holds access, how the credential is released and logged, and which systems the account reaches. Schedule a documented test that proves the account works and that its use triggers an alert, then confirm the credential was rotated afterward.
No risk-based reauthentication
Sessions that stay valid for a long time after a sign-in, regardless of what the user then does, leave privileged actions exposed to a stolen or unattended session. Review how the platform decides when to ask for a fresh factor, such as before changing security settings, exporting data or after a change in device or location. Verify the behavior in a test session rather than relying on the configuration page alone, and document the signals the rule uses and the actions that trigger it.
Evidence limited to screenshots
A screenshot of a configuration page shows one moment and cannot be re-run by an assessor. Auditors usually want exported configuration, sign-in and factor-enrollment logs, and records of the tests that show controls working. Decide which settings are exported on a schedule to version control or a log store, who reviews them, and how long they are retained. Ask the implementation partner and your own team to show that a sample of authentication events can be pulled for any chosen date range.
PR.AA-03 questions buyers ask before hiring help
How much effort does PR.AA-03 authentication take to implement?
The effort depends mostly on how many systems need to be brought under strong authentication and how many of them already support it. PR.AA-03 asks that users, services and hardware are authenticated, and NIST's Implementation Examples point to four practices: requiring multifactor authentication, enforcing minimum authenticator strength, reauthenticating based on risk, and keeping emergency access for accounts needed for safety. Applications that already sit behind a central login are far cheaper to bring in line than standalone applications with local passwords. Ask any partner to list each system, its current login method and whether it supports a second factor before estimating anything.
Can our team meet PR.AA-03 in-house without outside help?
Many teams can, provided they have someone who owns identity infrastructure and can run changes across applications. The work splits into a configuration effort (enrolling second factors, setting authenticator policies, writing reauthentication rules) and a documentation effort (showing the policy, the enrollment records and the exception process). Teams often struggle with the second part because assessors ask for evidence that the controls operate over time, not only that they were switched on. A partner can prepare that evidence trail, but the organization keeps ownership of the policy and the decisions behind it.
What does the work need from our staff?
Expect to provide an identity administrator, an owner for each application, someone who can approve policy exceptions, and time from a help desk lead who handles account recovery. The application owners matter most, because each one must confirm how its login works and whether it can enforce a second factor. Security or compliance staff should also be available to review the authenticator standard and the emergency access procedure, since those decisions reflect the organization's own risk appetite.
How long does PR.AA-03 take to implement?
The timeline depends on the number of systems in scope, the state of the current identity platform and how many applications need changes. No duration has been established for this work in the sources used for this page, so ask any partner to provide a timeline tied to a written list of systems and milestones. Confirm with your own environment which applications can accept central single sign-on and which will need custom work, because those differences drive most of the schedule.
Does NIST certify that we comply with PR.AA-03?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. Alignment with PR.AA-03 is a self-assessed or independently reviewed claim, not a certificate. If a customer or regulator asks for proof, the organization should ask an independent assessor to review its evidence and write a report, since only an independent auditor or assessor can issue that report. A partner can prepare the systems and evidence but cannot issue the conclusion.
What should we ask a partner to include in a fixed-scope quote?
Ask for a written scope that names each in-scope identity system, application and hardware class, along with the authenticator types to be supported and the reauthentication rules to be applied. The quote should list deliverables such as configuration changes, a documented authenticator standard, an emergency access procedure, test records and an evidence index mapped to PR.AA-03. Ask which items are one-time work, which recur (for example, upgrades, reviews or retainer support), and what is excluded, such as changes inside third-party software or work done by your own staff. Most DeployOpen engagements are fixed-scope and agreed in writing before work starts, so request the scope in that form.
Which open-source platforms can support PR.AA-03 multifactor authentication?
Several open-source identity platforms can enforce second factors, but their capabilities differ. authentik's authenticator validation stage checks enrolled factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, and static recovery codes. FreeIPA supports HOTP and TOTP tokens, including hardware tokens such as YubiKeys. Keycloak provides single sign-on across applications and can broker logins to existing identity providers. Confirm each platform's current factor list, licensing and upgrade path against the vendor's documentation before selecting one, because the factors supported change over time.
How DeployOpen prepares PR.AA-03 authentication evidence
DeployOpen works on PR.AA-03 Authentication as an implementation partner. We set up and document the authentication controls inside your own infrastructure, then prepare the evidence your organization presents to an assessor. Your organization owns the control; only an independent auditor or assessor issues a report or certificate.
How we scope
- Agree in writing which systems, user populations and services fall under PR.AA-03 for your organization.
- Record which second factors, authenticator types and reauthentication rules apply to each system before work starts.
- Confirm how emergency access to safety-critical accounts is defined, owned and tested as part of the agreed scope.
How we build
- Configure multifactor authentication in the self-hosted identity platform, such as authentik, FreeIPA or Keycloak, as agreed.
- Set minimum authenticator strength rules and enforce them through policy settings your team can review.
- Build risk-based reauthentication and break-glass access paths, then test each path against the documented requirement.
How we hand over
- Deliver configuration records, test results and a control narrative mapping each implementation to PR.AA-03.
- Provide evidence packs such as login logs, enrollment records and emergency access test records for your assessor.
- Train your administrators to operate, review and change the authentication settings after handover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
- Ongoing support, upgrades and continuous testing of the authentication setup are available as a retainer.
- Ask any proposed partner to confirm in writing which evidence they prepare and which parts only your assessor can issue.
