03.05.01 User identification and authentication guide

What 03.05.01 user identification and authentication asks for under NIST SP 800-171

If your contract now requires NIST SP 800-171 Rev. 3, requirement 03.05.01 asks for three things: every system user must be uniquely identified and authenticated, that identity must be carried through to the processes that act on the user's behalf, and users must re-authenticate in circumstances the organization defines. The requirement sounds simple, but assessors treat it as foundational because nearly every other access and accountability control depends on it. If an access control cannot be tied to one named person, the audit log, the least privilege decision and the incident investigation all lose their meaning. Shared and anonymous accounts are the usual failure: when several people sign in as the same account, no record can show who changed a configuration or exported a CUI file, and an assessor will not accept a control that cannot attribute actions to an individual.

The one organization-defined parameter in this requirement is the list of circumstances or situations that require re-authentication. NIST does not assign that value. If the federal agency that holds your contract does not specify it, your organization must define it, and SP 800-171A Rev. 3 checks that the value exists as a separate determination statement. Confirm the agency's position in writing before you start, then document your triggers, such as privilege elevation, access to CUI repositories after a period of inactivity, or changes in session context. Three areas usually make the requirement hard in practice: shared accounts used by operations teams, service accounts that run jobs under human credentials, and applications that maintain their own login tables outside the corporate directory. Each needs an inventory, an owner and a decision on whether it is replaced, federated or formally documented as an exception in the system security plan.

Which systems, users and teams 03.05.01 applies to in a CUI enclave

Requirement 03.05.01 applies wherever a user can reach a system that stores, processes or transmits CUI, so scope starts with the boundary and works outward to people and identity services. The cards below cover the decisions that most change the identification and authentication effort, from which systems sit inside the boundary to whether the directory is shared with non-CUI business systems.

Systems inside the CUI boundary

Start with the system security plan and data flow diagrams to list every system that stores, processes or transmits CUI, including backups, admin consoles and collaboration tools that receive CUI attachments. Each of these needs unique user identification and authentication before any access is granted. Confirm the boundary with your assessor early, because a system left outside the enclave still needs an explanation of how CUI cannot reach it.

Employees and general staff

Employees who handle CUI need individual accounts, so shared logins for teams or shifts fail the unique identification expectation. Count every person who can view CUI, including those who only receive reports or open shared drives. Each account should map to one named person and be traceable in audit records.

Administrators and privileged accounts

Administrators, database owners and security staff hold accounts that can change or bypass controls, so they need separate identities from their everyday accounts. Shared root or domain administrator logins are a common finding. Ask which personal admin identities exist, how elevation is recorded, and who can create new privileged accounts.

Contractors and external users

Contractors, subcontractors, auditors and partner staff who reach the enclave need identities that show they are not employees. Their accounts usually expire on a contract date and must be removed when the work ends. Decide whether they get accounts in your directory or federated access through their own organization, because that choice changes who controls the lifecycle.

Service accounts and automated processes

Service accounts, scheduled jobs and integration processes act on behalf of users and must be associated with an accountable owner. Interactive sign-in is rarely used for them, so document how each one authenticates and who answers for its activity. Missing owners are a frequent gap when teams inventory processes that run under shared credentials.

Shared directories and SaaS sign-in

A directory shared with non-CUI business systems brings those systems into the identity scope, because an account compromise there can reach the enclave. Applications that delegate sign-in to a central identity provider keep authentication in one reviewable place, while applications with local accounts need separate reviews. Confirm which SaaS applications receive CUI and whether their sign-in is federated.

How an assessor tests 03.05.01 under SP 800-171A Rev. 3

This table maps each assessment method in SP 800-171A Rev. 3 to the evidence an assessor requests for 03.05.01, and notes where organizations usually fall short. Read it as a preparation checklist: each row shows what to have ready before the assessor arrives. The main takeaway is that the re-authentication trigger list and the unique identity test carry most of the weight.

Assessment method	Evidence the assessor requests	Common findings
Examine: identification and authentication policy and procedures	Written identification and authentication policy and procedures that name owners, scope and review dates, and show how unique user identities are issued and used	Policy exists but does not cover service accounts, contractors or privileged users; no evidence of periodic review
Examine: list of circumstances requiring re-authentication	A documented list of the defined circumstances or situations that trigger re-authentication, such as session timeouts, privilege elevation or access to CUI	Re-authentication triggers are undefined, vague or not documented, which leaves the organization-defined parameter unset
Examine: system design documentation	Architecture and configuration records showing how user identities flow to applications, how processes act on behalf of users and where re-authentication is enforced	Design documents omit identity flows for batch jobs or integrations, so the assessor cannot trace process-to-user association
Interview: personnel with identification and authentication responsibilities	Discussion with identity administrators on how accounts are created, linked to individuals and removed, and how re-authentication triggers are configured	Administrators describe practices that differ from the written procedure or cannot explain the trigger list
Interview: personnel with system operations responsibilities	Discussion with operators on how the system enforces unique identification, handles shared credentials and responds when re-authentication fails	Operators report shared logins for maintenance or on-call work that the policy does not allow
Test: processes for uniquely identifying and authenticating users	Live demonstration or sample review showing that each user signs in with an individual identity and that a defined trigger forces re-authentication	Sampled accounts share credentials, or a defined trigger does not force re-authentication in testing
Test: processes acting on behalf of users	Evidence that background processes and automated jobs run under an identity linked to a named user or an accountable owner	Services run under generic or default accounts with no unique identity or accountable owner
Determination: ODP value defined	Documented value for the re-authentication circumstances, approved and traceable to the policy and the system security plan	The parameter is referenced in the policy but no value is recorded, which fails the defined-parameter check

Implementing unique identity and re-authentication in the right order

The sequence moves from knowing every account to proving each one maps to a single person or service, then to enforcing re-authentication in configuration and documenting the result. Following the order keeps evidence consistent for the assessor and avoids rework.

Inventory every account type and system
Start by listing every system that accepts sign-in in the CUI boundary, including applications, operating systems, network devices, databases, cloud consoles, service accounts and administrative tools. For each one, record the account types it supports, where accounts are created, and who can create them. The output is an account inventory that shows every path into the system. The step is complete when the system owner for each entry has confirmed the list, and nothing in the boundary is left unaccounted for.
Establish one authoritative identity per user
Decide which directory or identity source is the system of record for people, such as an existing corporate directory, and require every account to trace back to one person in that source. Identify duplicate accounts, personal accounts used for work and accounts with no named owner. The output is an identity source decision and a mapping of each user to a single identifier. The step is complete when the mapping can answer, for any account, who the person is and whether they are still employed or contracted.
Route application sign-in through a central provider
Connect applications to one identity provider so that users authenticate once against the authoritative source and applications accept the result, rather than storing separate local credentials. Where an application cannot delegate sign-in, document the local account, its owner and the reason it remains. Open-source identity providers can support several protocols, so confirm which ones your applications need before choosing. The output is an application integration list with the protocol used for each. The step is complete when every in-scope application either delegates sign-in or has a documented exception.
Define re-authentication circumstances as a written parameter
Requirement 03.05.01 leaves the circumstances for re-authentication to the organization, so write them down as a parameter the assessor can compare with system behavior. Typical entries cover session timeouts, privilege elevation, changes to security-relevant settings and access from a new location or device, but the list must reflect your own risk decisions. Have the system owner and the security lead approve it. The output is a signed parameter list. The step is complete when every system in the boundary maps to the list.
Configure session and re-authentication behavior
Apply the parameter list in each system, using the provider's session settings where possible and the application's own controls where they are not available. Test each circumstance by triggering it and recording that the user is prompted to authenticate again. Confirm that processes started on behalf of a user carry that user's unique identifier, so audit records and access decisions can be traced back to one person. The output is configuration evidence, such as exported settings and dated test results. The step is complete when each listed circumstance has a passing test on record.
Retire shared and orphaned accounts
Disable or remove shared logins, generic administrator accounts and accounts whose owners have left or changed roles. Where a shared account is operationally required, such as a break-glass account, record its custodian, the conditions for use and how each use is attributed to an individual. Reconcile the account inventory against the authoritative identity source on a schedule you define. The output is a removal record and a reconciliation report. The step is complete when the reconciliation shows no account without a valid owner.
Document the design and the evidence trail
Write a design document that describes the identity source, the provider and integration design, the re-authentication parameter list, the exceptions and the reconciliation process, and cross-reference it to the system security plan. Store configuration exports, test results and reconciliation reports where the assessor can retrieve them. The output is the design document and an evidence index. The step is complete when someone outside the project can follow the design and locate the evidence for each claim. Assessors test the process as well as the settings, so the document should describe how the controls operate over time.

Evidence that passes 03.05.01 and how to keep it current

An assessor testing 03.05.01 will look for written rules, a defined list of re-authentication triggers, documents that show how identity flows through the system, and records that tie real actions to individual people. Each artifact below ages differently, so each needs its own refresh rhythm between assessments.

Identification and authentication policy and procedures

This is the written rule set that says how users are uniquely identified, how they authenticate, and who owns each step. Assessors check that the document names the roles responsible for identity administration and that the procedures match what engineers actually do. Keep it current by assigning an owner, reviewing it at least annually, and recording each approved revision with a date and approver. Compare the procedures against the most recent account review to confirm the steps still happen as written.

Re-authentication circumstances with chosen values

03.05.01 leaves the triggers for re-authentication to the organization, so the assessor will ask for the written list and the specific values you picked, such as session age, privilege elevation, or access to CUI repositories. A vague statement that re-authentication happens "when appropriate" will not pass. Store the list under change control and tie each value to the configuration that enforces it. Review the values whenever the system boundary or the sensitivity of stored CUI changes.

System design documentation of identity flow

Diagrams and narratives showing where identities originate, which directory is authoritative, and how applications, administrators and processes receive and use identity. This is where the assessor confirms that a process acting for a user carries that user's unique identity. Mark each identity provider, federation link and provisioning path. Update the diagrams whenever you add an application, change a directory, or introduce a service account, and date each version.

Account inventory with no shared accounts

An export of every user account across the in-scope systems, showing a unique identifier, owner, status and the systems each account can reach. Assessors look for generic or shared logins and for accounts with no accountable owner. Pull the inventory from the directory and the applications themselves, then compare the two so orphaned local accounts stand out. Run a quarterly account review, document each disabled or removed account, and retain the review sign-offs as evidence.

Configuration exports showing enforced behavior

Exports or dated screenshots proving that the system enforces identification, authentication and re-authentication as the policy says. Examples include identity provider session settings, directory password and lockout policies, and application timeout values. Export configurations from the running system rather than from the design document, and store them in version control so each change has a commit, reviewer and reason. Re-export after every change request that touches authentication.

Access log sample tying actions to individuals

A sample of authentication and activity logs showing that each recorded action traces to one named user, including a re-authentication event where your triggers fired. This is the artifact that proves the design works in practice. Confirm that logs capture the unique identity rather than a shared or generic name, and that the sample covers both ordinary users and privileged accounts. Keep the log retention period aligned with your audit policy and pull a fresh sample before each assessment window.

What meeting 03.05.01 costs in money and effort

This table compares each cost component of meeting 03.05.01, who is paid for it, whether it is one-time or recurring, what moves it up or down, and how to limit it. No dollar figures are given because none are researched, so use the drivers to build a written scope and quote. The main takeaway is that identity consolidation and evidence upkeep usually cost more than licenses.

Cost component	One-time or recurring, and who is paid	What drives cost up or down	How to keep it down
Tooling or licenses	Recurring if commercial identity products are used. Paid to the vendor. Open-source options carry no license fee but still need hosting and staff time.	Number of applications, users and directory connectors. Commercial per-user pricing scales with headcount.	Ask for a quote that separates license, support and hosting. Self-hosted open-source identity providers such as authentik, FreeIPA, Keycloak and midPoint remove license spend, but confirm their support model.
Engineering time to consolidate identity	One-time for most work, with some recurring tuning. Paid to internal staff or an implementation partner under a fixed-scope agreement.	Number of applications that still hold local accounts, the state of the corporate directory, and whether duplicate or orphaned accounts exist.	Inventory applications and accounts before scoping. Clean the directory first, then route applications through one identity source so each user has one unique identifier.
Service and shared account handling	One-time to map and recurring to review. Paid to internal staff.	Number of service accounts, shared accounts and non-person processes that act for users.	Document each process-to-user association and owner. Retire shared accounts where possible so each process traces to an accountable identity.
Re-authentication configuration	One-time to define the circumstances, recurring to test. Paid to internal staff.	Number of defined circumstances, such as privileged actions, session age or sensitive transactions, and the number of systems that must enforce them.	Write the organization-defined circumstances once in the system security plan and enforce them through the identity provider where possible, rather than per application.
Evidence upkeep	Recurring. Paid to internal staff, and to a partner if one maintains the evidence set.	Frequency of access reviews, number of systems that need configuration exports, and how often identity sources change.	Automate exports of identity provider and directory configuration. Keep one evidence index that maps each determination statement to a current artifact.
External testing or review	Recurring or periodic. Paid to a security testing firm or consultant under a written scope.	Number of applications and identity flows in scope, and whether authentication testing covers bypass of re-authentication.	Scope the test to the identity flows that matter for 03.05.01. Ask for a fixed-scope quote with named deliverables.
Assessor sampling	Recurring per assessment cycle. Paid to the independent assessor or certification body.	Number of systems and user populations the assessor samples, and how well the evidence matches the stated procedures.	Before the assessment, confirm with the assessor which systems, populations and evidence formats they expect. Prepare evidence for each determination statement, including the ODP value for re-authentication.

Which self-hosted open-source tools can support 03.05.01 evidence

Four self-hosted open-source projects cover different parts of the identity flow that 03.05.01 depends on: sign-in for applications, single sign-on for Linux and UNIX, directory-based user federation, and account provisioning. Each one produces some evidence an assessor may examine, but none of them satisfies the requirement on its own.

authentik for application sign-in

authentik, licensed under MIT, acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to one place. For 03.05.01, its configuration and provider settings can show that each application requires a named user identity before access. Check that every application in the system security plan is actually routed through it, that local application accounts are disabled, and that re-authentication settings match the circumstances your organization defined as requiring it.

FreeIPA for Linux and UNIX sign-in

FreeIPA, licensed under GPL-3.0-or-later, provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. For 03.05.01, its directory of users and host records can show that individual identities are used to log on to servers and workstations rather than shared accounts. Confirm how privileged users are separated from everyday accounts, which hosts are enrolled, and whether any local accounts remain outside the directory that an assessor would need to explain.

Keycloak for directory-backed sign-in

Keycloak, licensed under Apache-2.0, uses user federation to connect to existing LDAP or Active Directory servers and synchronize users from them, so accounts managed in the corporate directory are the ones used for application sign-in. For 03.05.01, this shows that a single authoritative identity record exists for each user. Confirm how federated accounts are mapped, how disabled directory accounts are handled in Keycloak, and which sessions remain active after an account is removed at the source.

midPoint for account lifecycle records

midPoint, licensed under EUPL-1.2+, creates, updates and deletes accounts on connected systems based on user changes and role assignments. It keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery, with separately defined inbound and outbound rules. For 03.05.01, its reconciliation reports and provisioning history can show that each account on a connected system traces back to a recorded identity. Confirm that reconciliation runs on a schedule your organization sets, and that orphaned accounts found during discovery are investigated and resolved.

Who owns, implements and independently checks 03.05.01

Your organization owns the control. NIST's guidance places application and implementation of SP 800-171, and any compliance issues, with the federal agency that holds the contract or agreement with you, so the agency's expectations for identity should be captured in writing before design starts. Inside your own organization, the decisions that cannot be delegated are the policy for how users are identified and authenticated, the list of circumstances that require re-authentication, and the periodic review of accounts.

Identification and authentication policy: Someone accountable approves the policy and procedures that define unique user identity, shared account rules and the authentication standard for each system.
Re-authentication decisions: Your team defines the organization-defined parameter for 03.05.01, meaning the specific circumstances, such as session timeouts, privilege elevation or access to CUI repositories, that trigger a fresh sign-in.
Account reviews: Named owners confirm that each user account maps to a real person, that leavers are removed and that shared or orphaned accounts are investigated.
Exception handling: Your team decides and records any deviation from the policy, with the approver and the review date.

Confirm with your contracting officer or agreement owner which ODP values and evidence formats they expect before you finalize the policy.

Where 03.05.01 most often fails and how to close each gap

Most 03.05.01 findings come from gaps between how accounts are supposed to work and how they work in practice. The cards below cover the failures assessors see most often, the fix for each, and the artifact that shows the gap is closed. Assessors test what they can examine, so every fix should leave a record.

Shared administrator and team accounts

A shared login used by several administrators cannot show which person performed a given action, so the requirement to uniquely identify each user fails on its face. Replace shared accounts with named administrator accounts, and keep any break-glass account sealed, logged and tied to a documented approval. Ask for the account list from each system and confirm that every privileged login maps to one person. The artifact is an account inventory reconciled against the HR roster, plus a break-glass procedure with access logs.

Service accounts with no named owner

Service accounts run jobs, integrations and scheduled tasks, and they often carry standing credentials that nobody reviews. Each one needs a unique identity, a documented owner and a defined purpose, so that the process acting for the system can be traced to an accountable party. Check whether any service account is used interactively by people. The artifact is a register of service accounts with owners, purposes and the systems where each one authenticates.

Applications with local logins outside the central provider

An application that keeps its own user table creates a second identity store that the directory never disables. When someone leaves, their local account often survives. Route sign-in through a central identity provider where the application supports it. For example, authentik can act as the provider for applications over OpenID Connect, SAML, LDAP and proxy providers, and Keycloak can federate users from an existing LDAP or Active Directory server. The artifact is a list of applications with their authentication source and a test showing a disabled directory account can no longer sign in.

No defined re-authentication circumstances

The 03.05.01 parameter asks the organization to define the circumstances that require re-authentication, and an undefined list fails the requirement even when sessions are technically enforced. Write the list down, covering items such as privileged actions, elevated sessions, sensitive data access and idle timeouts, then configure each system to match. Confirm that the list in the policy matches the settings in the systems. The artifact is a signed list of circumstances with configuration screenshots or exports showing each one enforced.

Orphaned accounts after departures

Accounts left active after someone changes role or leaves are the most common finding in identity reviews. Removal often depends on a manual ticket that nobody closes, and local accounts in individual applications are missed entirely. Tie account disablement to the HR or identity source of truth, and reconcile system accounts against it on a schedule. Provisioning tools such as midPoint can create, update and delete accounts on connected systems from role assignments and run scheduled reconciliation. The artifact is a reconciliation report showing zero active accounts for departed personnel and the date each check ran.

Verbal assurance instead of recorded evidence

Teams often say that accounts are unique and re-authentication is enforced, but cannot show it. Assessors examine documents, interview staff and test the system, and a control described only in interviews will not satisfy the examine and test methods. Before the assessment, walk each claim through a document, a configuration export and a test run. Ask the system owner to demonstrate one login from a shared account attempt and one re-authentication event. The artifact is an evidence folder that maps each determination statement to a document, a configuration record and a test result.

What buyers ask about 03.05.01 cost, effort and outside help

How much effort does 03.05.01 take to implement?

The effort depends less on the requirement text and more on how many systems, identity sources and applications must agree on who each user is. 03.05.01 asks for unique identification and authentication of every user, association of that identity with processes acting for the user, and re-authentication in circumstances the organization defines. A small environment with one directory and a few applications can close most of the gap quickly. Effort rises sharply when accounts are created by hand in each application, shared or generic accounts exist, or service processes run under user identities. Ask any partner to size the work from an inventory of systems and account sources in the written scope.

Does 03.05.01 have a fixed cost I can get from a price list?

No. Costs come from the work needed to close the gap in your environment, plus the recurring cost of running the identity services. The one-time costs include assessing current identity sources, configuring the identity provider and directory, integrating applications, documenting procedures and collecting evidence. Recurring costs include administration, patching, monitoring and periodic review of re-authentication settings. DeployOpen does not publish a price list; a quote follows from a written scope that lists the systems, applications and deliverables covered.

What does the work need from our own staff?

Your staff must make decisions that only the organization can make, and they must provide access to the systems involved. Identity owners need to confirm who is a user, which accounts are shared or generic, and which processes act on a user's behalf. Application owners must confirm how their software authenticates users and whether it can delegate sign-in. Security staff must define the circumstances that trigger re-authentication and approve the procedures. Plan for these reviews to take place inside the engagement schedule, because delayed decisions usually extend the timeline more than technical work does.

Can our team implement 03.05.01 without outside help?

Yes, an experienced identity team can implement 03.05.01 without an outside partner, and many do. The questions to answer honestly are whether the team has capacity alongside current duties, whether it has built or operated the relevant identity platforms, and whether it can produce the policy, procedure and system design documentation that an assessor will examine. Outside help is most useful for scoping, for integrating several identity sources, and for preparing evidence in the form an assessor expects. Use a short internal pilot on one application to test the team's assumptions before committing to a full plan.

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

A partner such as DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside your own infrastructure. For this requirement, that can include configuring the identity provider, connecting applications, setting up directory synchronization and preparing the evidence an assessment will examine. A partner does not own your controls, decide your re-authentication policy on your behalf, or issue an assessment result. Only an independent assessor or certification body issues reports or certificates. Confirm these boundaries in the written scope before work starts.

Who decides which circumstances require re-authentication?

The organization decides. 03.05.01 leaves the re-authentication circumstances as an organization-defined parameter, and NIST does not assign those values. If a federal agency that holds the contract specifies the circumstances, the organization must follow them. If the agency does not, the organization must define them and document the reasoning, such as session age, privileged actions, changes in location or device, and access to CUI. An assessor will check that the list exists and that systems enforce it. Your security leadership should approve the list, and a partner can configure it once it is decided.

How does 03.05.01 differ from the Rev. 2 requirement still used in DoD contracts?

Rev. 2 requirement 3.5.1 is the closest counterpart, and NIST classifies the change to 03.05.01 as significant, with more detail and foundational tasks. CMMC Level 2 still assesses 3.5.1 under the Rev. 2 wording, and a DoD class deviation names Rev. 2 for contracting purposes, so contractors should not assume Rev. 3 wording is what they will be measured against today. Map your evidence to both the Rev. 2 requirement and the Rev. 3 determination statements, because a single set of records can usually serve both. Confirm the current contractual version with the contracting officer.

How DeployOpen scopes, implements and prepares evidence for 03.05.01

DeployOpen works on 03.05.01 as a fixed-scope implementation partner. We map which users, applications and directories fall inside the CUI boundary, then build and document the identity controls that the organization owns and an independent assessor will test. Evidence is handed over in the client's own environment.

How we scope

Inventory every user population that reaches systems handling CUI, including employees, contractors and service accounts.
Map which applications and directories issue or consume identities, and where re-authentication triggers must be defined.
Agree the organization-defined re-authentication circumstances in writing before build work starts, since the organization assigns them.
Record scope, deliverables and timelines in a written statement of work, with ongoing support available as a retainer.

How we build

Deploy self-hosted identity providers such as authentik, FreeIPA or Keycloak inside the client's own infrastructure.
Federate existing LDAP or Active Directory accounts so one unique identity per user is used for application sign-in.
Configure provisioning and deprovisioning with midPoint so account changes follow role assignments and HR-driven events.
Set session timeouts and re-authentication rules to match the documented circumstances, then test each rule against the configuration.

How we hand over

Deliver the identification and authentication policy and procedures, written for the client's own staff to own and update.
Provide the list of re-authentication circumstances and system design documentation that assessors examine under SP 800-171A.
Export configuration evidence and test results showing unique identities, process-to-user association and re-authentication behavior.
Walk the client's personnel with identity responsibilities through the interview topics an assessor is likely to raise.

How we support

Confirm with the client's assessor which evidence format and sampling approach they expect before final handover.
Keep the identity configuration current through upgrades, patching and changes, with retainer support where the client chooses it.
Re-run the 03.05.01 checks after significant directory, application or identity provider changes to keep evidence accurate.
Coordinate with the organization's assessor and SPRS owner. DeployOpen prepares evidence but does not issue assessment results.