IA.L2-3.5.2 Authentication: requirements and evidence

What IA.L2-3.5.2 authentication requires before any access is granted

IA.L2-3.5.2 asks you to authenticate or verify the identity of every user, every process acting for a user, and every device before it is allowed to reach an organizational system. It is a 5-point requirement that must be MET for your environment to reach Conditional or Final Level 2 status, and it cannot go on a POA&M because its point value is above 1. If a Level 2 assessment is on your calendar, treat this requirement as one you must close, not one you can defer. The assessor will test three things separately: users, processes acting for users, and devices. A gap in any one of them leaves the requirement NOT MET.

The Level 1 counterpart is IA.L1-b.1.vi, which applies the same authentication concept to Federal contract information rather than CUI. The most common failure in practice is not a missing login screen but a forgotten default credential: vendor accounts on appliances, network gear, printers, databases, service consoles and lab equipment that ship with a known username and password. The CMMC Assessment Guide expects those defaults to be changed immediately to something unique. Build an inventory of every system that has a local login, including equipment managed by operations or engineering teams outside IT, and confirm each one has been reset and documented.

This requirement is hard in mixed environments because identity is split across directories, cloud tenants, local accounts, service accounts and devices that cannot run an agent. Each path needs its own authentication decision, and the assessor will ask for evidence on each. Confirm with your identity team which systems authenticate against a central directory, which keep local accounts, and which accept shared credentials. Service accounts and machine-to-machine access are the usual gaps, since they authenticate processes rather than people. Also confirm that your authenticator management procedures and change records exist in final form, because the assessment objectives expect documented procedures and tested mechanisms, not only working logins.

Which systems, accounts and devices are in scope for authentication

IA.L2-3.5.2 applies to every path that reaches a system holding CUI, so scope starts with the systems and then works down to each account and device type. The cards below cover the decisions that most often change the amount of work, from the CUI boundary to third-party identity providers.

CUI systems and their authentication paths

Start with the systems that store, process or transmit CUI, then list every route that reaches them: console logins, web portals, VPN gateways, remote desktop and API endpoints. Each route is an access path the assessor will ask you to show is authenticated before access is granted. Confirm that no path bypasses the identity check, including emergency or break-glass access and direct database connections. Document the diagram and keep it current with your system security plan.

Human users and their sign-in methods

Every person with access to a CUI system needs an identity that is verified before access, whether they are employees, contractors or managed service staff. Check whether each application uses the same directory or keeps its own local password store, because local stores are often missed in inventories. Note how users sign in from managed and unmanaged endpoints, since the verification method may differ by route. Your evidence should show the verification step for each sign-in method, not only the directory policy.

Service accounts and processes acting for users

Scheduled jobs, integrations, and background services authenticate as processes, and 3.5.2 expects each of them to be verified too. Inventory every service account, its owner and the credential type it uses, including API keys and certificates. Shared service credentials used by several processes make it hard to show that each process is authenticated on its own. Record where each secret is stored and who can rotate it, because assessors will ask for the procedure as well as the account list.

Network devices and appliances with default logins

Firewalls, switches, routers, printers, storage arrays and out-of-band management interfaces often ship with default usernames and passwords. The CMMC Assessment Guide Level 2 says those defaults must be changed immediately to something unique, because defaults may be publicly known or easy to guess. Build an inventory that includes devices nobody thinks of as computers, and check the vendor documentation for each model. Record the date each default was changed, since that date becomes evidence.

Cloud and third-party identity providers

When sign-in for a CUI system relies on a cloud directory, a managed identity service or a partner's identity provider, that provider becomes part of your authentication boundary. Confirm which party configures, operates and logs the service, and whether it sits inside an environment that meets the applicable CMMC requirements. Identify the federation trust, the attributes passed to your systems and what happens when the provider is unavailable. Your contract and configuration records should show who is responsible for each authentication step.

Self-hosted identity providers in your own environment

Where identity runs inside your own infrastructure, the identity server is itself a CUI-adjacent system whose configuration and administrators must be controlled. Open-source options such as authentik, FreeIPA and Keycloak can act as the identity provider for applications, and each one needs its own scope decision. Decide which applications delegate sign-in to the central provider and which keep local accounts. Keep records of the provider version, the protocols enabled and the applications connected, so an assessor can trace each application back to a verified identity source.

How an assessor tests that each identity is verified

The first thing an assessor asks for is the written rules. For IA.L2-3.5.2, the assessment objects named in NIST SP 800-171A include the authenticator management procedures and the list of system authenticator types. The procedures should say which authenticators the organization accepts for users, processes and devices, how each is issued, how it is verified before use, and who approves exceptions. The authenticator list should match what the systems actually accept, so an assessor can compare the document against the live configuration.

Procedure scope: The document should cover all three identity types, not only human logins.
Authenticator inventory: List each type, such as passwords, certificates, tokens, keys or passkeys, and the systems that accept it.
Ownership: Name the role that maintains each procedure and the review cycle.
Default credentials: The procedure should require that vendor default usernames and passwords are changed to unique values before a device is placed in service.
Consistency: Procedures that describe a process the systems do not follow will be scored against the organization.

Before the assessment, confirm that the procedure and the authenticator list are in final form and match a sample of live systems.

Implementing authentication for every user, process and device

This sequence moves IA.L2-3.5.2 from an unknown set of sign-in paths to a documented, verified and tested state in which every user, process and device proves its identity before it reaches an organizational system. Each step produces an artifact an assessor can examine against the NIST SP 800-171A objectives.

Inventory every authentication path and default credential
The organization's IT and security staff list every system that grants access, including cloud consoles, network devices, servers, databases, applications, service accounts, scheduled jobs, and devices that connect to the network. For each entry, record how it verifies identity today and whether it ships with or still uses a default username or password. The output is a written authentication inventory that names the owner of each path. Confirm the inventory is complete by comparing it against the system boundary in the system security plan and against directory and asset records, since gaps often sit in appliances and service accounts.
Define authenticator types and management procedures
The security team, with system owners, documents which authenticator types are permitted for each class of account, such as passwords, hardware tokens, certificates, passkeys and one-time codes, and who may issue, reset, revoke and store them. Assessors look for written authenticator management procedures and a list of the authenticator types in use, so this document is a core deliverable. The output is an approved procedure with a named owner and a dated version history. Confirm that the procedure matches what the systems actually do, not only what the policy intends.
Enforce verification at each access point
Engineers configure each system in the inventory so that no user, process or device reaches organizational data until its identity has been verified against an approved authenticator. This includes local logons, remote access gateways, administrative consoles, API clients and service-to-service calls. Where a system cannot verify a process or device natively, the team documents a compensating boundary control and records it in the plan of action. The output is a configuration record for each access point that shows the verification step and the authenticator it uses.
Replace default credentials with unique ones
Administrators change every default username and password on newly deployed or inherited equipment immediately, and replace them with unique values that are stored in an approved secrets vault or password manager. The CMMC Assessment Guide for Level 2 states that defaults may be publicly known or easy to guess, so assessors check this closely on network devices, firmware consoles and appliances. The output is a signed checklist per device class showing the default was changed and the new credential was recorded. Confirm this with a sample of devices during testing, not only from the checklist.
Centralize sign-in where practical
Where the architecture allows, the team routes applications and services through a single identity provider so that verification rules, multifactor settings and account lifecycle changes are applied in one place. Open-source options such as authentik, FreeIPA and Keycloak can act as identity providers for applications using protocols like OpenID Connect, SAML, LDAP or Kerberos, depending on the environment. The team must confirm that each candidate product supports the protocols and authenticator types the organization needs before selecting it. The output is an architecture decision record and a list of applications that now delegate sign-in.
Test authentication against each access path
An independent tester or internal reviewer attempts access through every path in the inventory without a valid identity, with a default credential, and with an expired or revoked authenticator, then confirms that each attempt is refused. The reviewer also samples authenticator management records, including issuance, reset and revocation tickets, and checks them against the procedure. Results are recorded with the test date, the path tested, and the observed outcome. The output is a test report with evidence in final form. Any failure is logged in the plan of action and remediated before the requirement is claimed as MET.
Keep the evidence current
The organization assigns an owner to review the authentication inventory, authenticator procedure and configuration records on a recurring schedule it sets, and to update them after any new system, vendor appliance or identity change. Change control records for authenticator management are kept alongside audit records so that the history can be shown to an assessor. The output is a maintained evidence set that reflects the current environment. Confirm the review cadence with the organization's own governance rules and any contract requirements that apply.

Why default credentials on devices fail this requirement

Under IA.L2-3.5.2, an assessor will not accept a device that still answers to its factory login. The CMMC Assessment Guide for Level 2 says default usernames and passwords shipped with devices must be changed immediately to something unique, because defaults may be publicly known or easy to guess. A default credential is effectively an authenticator the organization did not choose and cannot prove is private, so verifying identity at that point means very little. The practical question for the assessor is whether every device that touches a system with CUI has had its vendor logins replaced, and whether the organization can show when and how that happened.

Assessors usually find default credentials by looking where the organization has not been looking. Appliances, printers and multifunction devices, switches, routers, firewalls, out-of-band management interfaces, uninterruptible power supplies, cameras and legacy servers often ship with administrative accounts that never appear in the directory. Ask the assessor's likely questions before they do: which devices have a web or console login, which vendor accounts exist on each, and whether any service or maintenance account was created at install time. Scan the network for management interfaces, then compare what you find against the vendor documentation for each model. Confirm the vendor's default account list for your exact firmware, because defaults differ between versions.

Build a device account register as a controlled record. For each device, list the make, model, firmware version, location, owner, every local account and its purpose, where the credential is stored, the date it was changed and the person who changed it. Include accounts that cannot be disabled and record how they are protected, for example by a unique password held in a vault with restricted access. Keep the register under change control so that a new device cannot join the environment without an entry. Ask any implementation partner or internal team to show how the register feeds the system security plan, and confirm with your assessor that the register format and retention meet their expectations before the assessment begins.

Evidence that passes IA.L2-3.5.2 and how to keep it current

An assessor testing IA.L2-3.5.2 looks for a set of artifacts that show how authenticators are managed, what they are, and that they were changed under control. Each artifact below answers one part of the question, and each must be in final form, because drafts do not count toward a MET finding.

Authenticator management procedure

This is the written procedure that governs how user, process and device authenticators are issued, verified, changed and retired. Assessors test whether the procedure matches what the systems actually do, so the document should name the systems, the owners and the steps for each authenticator type. Check that it is approved, dated, versioned and stored in your document control system, not in a working folder. A procedure that describes a process nobody follows will fail the interview as well as the document review.

List of system authenticator types

Assessors expect a current list of every authenticator type in use, such as passwords, one-time codes, passkeys, certificates, Kerberos tickets and API tokens for service processes. For each type, record which systems use it and who manages it. Missing types are a common finding, especially service accounts and device certificates that sit outside the directory. Reconcile this list against the identity provider and system configurations at least once per assessment cycle.

Identity provider configuration exports

Configuration exports from the identity provider show the authentication settings that are actually enforced, including password policy, MFA enrollment and the applications that delegate sign-in. Products such as authentik, FreeIPA, Keycloak and Zitadel can produce these exports, but you must confirm the export format and whether it captures realm, provider or policy settings in full. Date each export, store it as a read-only record, and keep the export that matches the assessment period.

Default credential change records

The CMMC Assessment Guide expects default usernames and passwords shipped with devices to be changed immediately to something unique. Keep a record for each device or appliance that shows the default credential was replaced, the date, the person who made the change and the ticket or change request that authorized it. Include switches, firewalls, hypervisors, printers and management interfaces. Confirm that no default credentials remain by sampling devices against the inventory.

Device account inventory and change records

The device account inventory lists the accounts and authenticators bound to each device and process, with their owners and status. Pair it with change control and audit records for authenticator changes, such as password resets, certificate renewals, token rotations and account disablement. Assessors trace a sample of changes back to an approved request and a logged event. Gaps usually appear where manual changes happen on appliances that do not forward events to central logging.

Authenticator test results

Test results show that the authenticator management mechanisms work as the procedure says. Keep dated results from tests such as failed login attempts, forced password resets, disabled-account checks and attempts to log in with a default credential. Record who ran each test, the configuration tested and the outcome, and retain the results with the assessment package. Retest after any change to the identity provider, because a result from an earlier configuration does not show the current state.

What meeting IA.L2-3.5.2 costs in money and effort

This table breaks the cost of meeting IA.L2-3.5.2 into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are published here, so use the table to structure requests for quotes and internal budgets. The main takeaway is that the largest variable is how many applications, devices and accounts must be brought under verified authentication.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Identity tooling or licenses	Software vendor, or none for self-hosted open source	Recurring if licensed; the open-source platform itself carries no license fee	Commercial licensing model, number of identities, and whether hosting is self-managed
Integration engineering for applications	Internal engineers or an implementation partner	One-time, with later changes	Number of applications, protocols they support (OIDC, SAML, LDAP, RADIUS) and custom sign-in flows
Device and process authentication work	Internal IT or platform engineering	One-time, with recurring upkeep	Count of network devices, service accounts and non-interactive processes that need their own verified identity
Default credential remediation	Internal administrators or an implementation partner	One-time per device class, then recurring on new hardware	Number of appliances, printers, network gear and vendor-supplied accounts that ship with defaults
Authenticator management procedures	Internal compliance or security staff	One-time drafting, recurring review	Number of authenticator types in use and how often procedures change
Evidence upkeep and change records	Internal compliance staff	Recurring	Frequency of authenticator changes, how many change control records are kept and how well logs are retained
Independent review or testing	Independent assessor or testing firm, scoped separately	Periodic	Scope of the review, number of systems tested and whether the assessor is independent of the implementer
Assessor sampling and assessment fees	Authorized or accredited assessor	Per assessment cycle	Number of systems and authenticator types sampled, and the assessment scope agreed in advance

Who owns, implements and assesses authentication controls

The organization remains accountable for IA.L2-3.5.2 because the requirement applies to its own systems, users, processes and devices. Internal staff decide who is authorized to hold an account, which authenticators are acceptable, how default credentials are retired, and who answers for exceptions. An assessor will ask these owners to explain the decisions, so they cannot be delegated away.

Policy decisions: Approve the authenticator management procedure and the list of authenticator types the system accepts.
Account lifecycle ownership: Name who approves creating, changing and removing user, service and device accounts.
Default credential control: Confirm that vendor default usernames and passwords on appliances, databases and management consoles are replaced before go-live.
Change records: Keep the change control tickets that show when authenticators or identity settings were modified and who approved them.
Final sign-off: Decide when evidence is in final form and when the requirement is ready for assessment.

Before any outside party is engaged, confirm that each of these owners can name the artifact that proves their decision.

Common gaps that cause IA.L2-3.5.2 to be scored NOT MET

Most IA.L2-3.5.2 findings come from a few recurring patterns: credentials that were never changed, accounts that sit outside the identity provider, and procedures that exist on paper only. Because this requirement is worth 5 points and cannot go on a POA&M, each gap below can block Conditional or Final Level 2 status on its own.

Default credentials left on appliances

Firewalls, switches, storage arrays, printers and management consoles often ship with vendor usernames and passwords that are widely documented. The CMMC Assessment Guide Level 2 expects these to be changed immediately to something unique. Check each appliance type in the asset inventory, log in with the vendor default list in hand, and record the date each credential was replaced. Ask the vendor where the default lives and whether a first-boot wizard enforces the change.

Shared service account passwords

Service accounts that run backups, scheduled jobs or integrations often share one password across several systems and are known to more people than the team that owns them. Assessors test whether each process acting for a user is authenticated as its own identity before it reaches the system. Confirm that every service account has a named owner, a unique credential, and a vaulted secret, and that a departing administrator does not hold the only copy.

Local logins outside the identity provider

Applications that keep their own user tables, or that were installed with a local administrator account, create a second sign-in path that bypasses central authentication. Each one must be inventoried, and its local accounts must either be disabled or justified as an authenticator the organization manages. Compare the application list against the identity provider's connected applications. Any system that accepts a password the directory does not know is a finding waiting to happen.

Authenticator procedures that exist only as drafts

Assessors look for authenticator management procedures and a list of the system authenticator types. A procedure marked draft, unsigned or never followed does not satisfy the objective, because the requirement is met only when evidence is in final form. Review each procedure for an owner, an approval date and a current version, then walk through one real authenticator issuance and one reset to confirm the document matches what staff actually do.

No change records for authenticator changes

Assessors test authenticator management mechanisms and look for change control records covering authenticator creation, reset and revocation, along with the audit records that show them. Without tickets or logged events, the organization cannot show that a credential was ever changed. Confirm that every credential change, including default password replacement and service account rotation, produces a ticket or an identity provider event that can be exported for the assessment.

Unverified devices and processes

The requirement covers devices and processes as well as people, so a laptop, scanner or script that connects without its own authentication can fail the objective even when every user signs in correctly. Build a list of device and process types that reach the system, then confirm each has a certificate, a machine account or another verified credential. Test by attempting access from an unregistered device, which should be refused.

Questions buyers ask about IA.L2-3.5.2 authentication

Can we implement IA.L2-3.5.2 in-house, or do we need a partner?

Most organizations can do the technical work in-house if they have identity engineers and enough time to document it, and a partner helps when the team lacks capacity or experience with assessment evidence. The requirement asks you to verify the identity of each user, each process acting for a user and each device before it reaches organizational systems, and NIST SP 800-171A breaks this into three assessment objectives. In-house, your cost is staff time for designing the identity provider, enforcing authentication on every system, writing authenticator management procedures and collecting evidence. With a partner, you pay for the scope agreed in writing, such as configuring a self-hosted identity platform and preparing the evidence set. Ownership of the controls stays with your organization either way. Ask any partner to show how the scope maps each objective to a specific system and a specific artifact.

Can IA.L2-3.5.2 go on a POA&M?

No. IA.L2-3.5.2 is worth 5 points under the CMMC Scoring Methodology, and 32 CFR 170.21(a)(2) does not allow a requirement worth more than 1 point on a plan of action and milestones. If it is NOT MET, its 5 points are subtracted from the maximum score of 110, and it must be MET to reach Conditional or Final Level 2 status. In practice, authentication has to work before the assessment, not after it. A POA&M can still track other gaps, but an unfinished identity check blocks status. Build a pre-assessment test that walks every login path, including service accounts, API clients, administrative consoles and network devices. Confirm the current assessment phase on the DoW CIO About page before you set your schedule, because the Department of War suspended Phase II on 13 July 2026.

What does the authentication work need from our team?

It needs four kinds of contribution, each with a named owner:

An owner for the identity provider and its configuration, including who can change login policies and how those changes are approved
An inventory of every user type, process account and device class that reaches organizational systems, with the authenticator each one uses
Access to change control records, because assessors check how authenticators are issued, changed and retired
Hands-on support to change default usernames and passwords on shipped devices immediately to unique values, since defaults may be publicly known or easy to guess

The evidence that assessors typically examine includes authenticator management procedures, the list of system authenticator types, change control records, audit records, and test results showing the mechanisms work. Your engineers should expect to run these tests themselves and explain the results to an assessor.

How long does IA.L2-3.5.2 take to implement?

No supplied source gives a duration for this work, so treat any single number you hear with caution. The main drivers are the number of systems and login paths, whether you already have a directory and single sign-on, how many legacy applications need a proxy or a protocol change, how many devices still use default credentials, and how many people must review the procedures. Organizations with a clean directory and few legacy systems move faster than those with many standalone applications. Evidence also takes time, because each objective must be satisfied with evidence in final form, not drafts. Ask any partner for a fixed-scope written timeline that lists the systems in scope, the deliverables and the dependencies on your staff. For the schedule of the assessment itself, check the current status on the DoW CIO About page, since the timing of Phase II was changed in July 2026.

Does self-hosting an open-source identity platform remove license cost?

It removes the software license fee, but it does not remove the cost of running the platform. The candidate platforms carry different licenses: authentik is MIT, FreeIPA is GPL-3.0-or-later, Keycloak is Apache-2.0, and Zitadel is AGPL-3.0-only. Have counsel review the AGPL obligations before you modify the code and offer it to users over a network. The costs that remain are one-time and recurring. One-time costs include architecture and design, migration of existing accounts, integration with each application, testing and evidence preparation. Recurring costs include the infrastructure inside your environment, operations staff, upgrades, patching, support, training and any hardware security keys or MFA services you buy. Ask for a quote that lists each of these lines separately, so you can compare the total cost of ownership with a commercial identity service.

What can a partner not do for the assessment?

A partner prepares systems, controls and evidence, but it cannot issue assessment results, scores, reports or certificates. Only an independent assessor can do that. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, while Level 2 self-assessments are conducted by your organization. Because the Phase II certification requirement is suspended under the 13 July 2026 Department of War action, confirm which path applies to your contracts before you plan. A partner also cannot guarantee that IA.L2-3.5.2 will be scored MET, and it cannot sign the affirmation that your organization submits. Keep the partner's role in writing: it designs and configures the identity controls and documents the evidence, your organization owns the controls and attests to them, and the assessor tests them independently.

How DeployOpen prepares authentication controls and evidence

DeployOpen plans, implements and documents identity controls for IA.L2-3.5.2 inside your own infrastructure, using self-hosted open-source identity providers. We prepare the systems and evidence an assessor will examine, while your organization owns the control and an independent assessor makes the determination.

How we scope

Engagements are fixed-scope, with the systems, identity sources and applications in scope agreed in writing before work starts.
The written scope lists every authenticated user, process and device population that must be verified before access to CUI systems.
Scope also records which default credentials on devices and applications must be replaced, and who approves each change.

How we build

We configure the chosen identity provider, such as authentik, FreeIPA, Keycloak or Zitadel, to verify each user before system access.
We replace vendor default usernames and passwords on in-scope devices and applications with unique credentials under documented procedures.
We test authentication mechanisms for users, processes and devices, recording the results against the SP 800-171A objectives for 3.5.2.

How we hand over

You receive authenticator management procedures, the list of authenticator types in use, and change control records for authenticator changes.
Configuration exports, test results and audit records are delivered in final form, so your team can show each objective is satisfied.
Documentation names the owner of each authenticator process so your organization can operate and defend it after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers when identity platforms change or new applications join scope.
Retainers can cover periodic review of authenticator settings and default credential checks on newly added devices.
Your independent assessor or certification body remains responsible for any assessment outcome, report or certificate.