IA.L2-3.5.3 Multifactor authentication: evidence guide

What the IA.L2-3.5.3 multifactor authentication requirement asks for

IA.L2-3.5.3 asks you to use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.5.3, a derived requirement in the Identification and Authentication family. If your organization stores, processes or transmits CUI, the question an assessor will ask is not whether you have MFA somewhere, but whether every access path in your system scope that the requirement names is covered. A contractor can have MFA on its email and still fail this requirement if an administrator logs on locally to a server with a password alone. The risk behind the requirement is stolen or guessed passwords. A password that is phished, reused from a breach or captured by malware gives an attacker the same access as the user. A second factor makes that captured credential insufficient on its own. The requirement is hard in practice for three reasons: legacy applications may accept only a username and password, service accounts often cannot answer a prompt, and administrative consoles or hypervisors may have their own login paths that were never added to the identity provider. Each of these needs an explicit decision, documented in your system security plan, about how it is covered or where the exception lives. Under 32 CFR 170.24, IA.L2-3.5.3 is one of only two Level 2 requirements scored with partial credit. Failing to implement MFA for any users costs 5 points, and covering only remote and privileged users costs 3 points. Either deduction is above the 1-point threshold, so it cannot be carried on a POA&M. Before you plan any work, confirm the current status of CMMC Phase II with the Department of War and your contracting officer. The DoW suspended Phase II on 13 July 2026 and started a review, while Phase I self-assessments and DFARS 252.204-7012 obligations remain in place.

Which accounts, access paths and devices fall under MFA scope

IA.L2-3.5.3 does not ask for MFA everywhere. It names specific access paths, and each one you include or exclude changes the systems you configure, the evidence you collect and the questions an assessor asks. Work through these scoping decisions before you configure anything, and record the result in your system security plan.

Identify privileged accounts first

Identifying privileged accounts is the first assessment objective in NIST SP 800-171A for this requirement, so the assessor will ask for the list before anything else. Build it from directory group memberships, local administrator groups, hypervisor roles, cloud subscription owners and service accounts with elevated rights. Check it against exported account lists and audit records, because a privileged account missing from the list is a missing MFA control.

Local console and hypervisor access

MFA for local access to privileged accounts covers people who sit at a server console, a hypervisor host, a physical appliance or a privileged workstation. Decide whether break-glass local accounts are in scope, and how MFA works when a console has no network path to an identity provider. Document the method for each platform, since assessors may test the mechanism that implements MFA rather than the policy text.

Network access to privileged accounts

Remote administration over SSH, RDP, management consoles, cloud portals and privileged API sessions all count as network access to privileged accounts. Each entry point needs its own check, because MFA enforced at the VPN does not automatically cover a jump host or a direct SSH path. Map every administrative route to an MFA step and test the routes that bypass the main login page.

Network access for non-privileged users

Standard users who reach CUI systems over the network must also use MFA under this requirement, which often surprises teams that scoped MFA to administrators only. Include email, file shares, collaboration tools and line-of-business applications that hold CUI. Remote staff are the highest-risk group in this card, so confirm that VPN, web and mobile sign-ins all prompt for a second factor.

Mobile devices that reach CUI

The CMMC Assessment Guide Level 2 states that MFA is required when a mobile device is used to access a system or application containing CUI. Decide which phones, tablets and laptops are approved for CUI access and how each one authenticates. Check that mobile mail clients, apps and browsers sessions honor the same second factor as desktop sessions.

Link MFA to remote and maintenance controls

IA.L2-3.5.3 works alongside the remote access requirements AC.L2-3.1.12 to 3.1.15 and the nonlocal maintenance requirement MA.L2-3.7.5. Remote sessions and vendor maintenance sessions therefore need MFA even when the vendor works from their own network. Note in your scoping record which remote and maintenance paths rely on this control, so the same evidence can support those requirements.

How an assessor tests MFA against the four assessment objectives

This table compares the four NIST SP 800-171A assessment objectives for IA.L2-3.5.3, showing how an assessor tests each one, what evidence to prepare and where findings usually arise. Read each row as one objective that must be satisfied before the requirement can be scored as MET.

Objective	How the assessor tests it	Evidence requested	Common finding
Identify privileged accounts	Reviews the account list and asks how administrative and other privileged roles are defined and assigned, then samples accounts against that definition.	Current account lists with role or group membership, privilege assignment records and the criteria used to classify accounts as privileged.	Privileged accounts sit in groups that were never reviewed, or service and break-glass accounts are missing from the list.
MFA for local access to privileged accounts	Attempts local logon to sampled privileged accounts and checks whether a second factor is required, then reviews the configuration of the authentication stack.	Configuration exports or screenshots showing the second factor enforced for console or local logon, plus test results from a sampled logon.	Console or local administrator logon uses only a password because the MFA policy covers only web or VPN access.
MFA for network access to privileged accounts	Tests remote and network logons to privileged accounts through each access path (VPN, remote desktop, administrative portals, directory consoles) and confirms a second factor is presented.	Policy or flow configuration for each network path, login test records, and the mechanism that enforces the second factor for those paths.	One administrative path, often a legacy tool or API, skips the MFA stage while the main portal enforces it.
MFA for network access to non-privileged accounts	Samples non-privileged users who reach CUI systems over the network, tests their login flows and reviews whether the same enforcement applies to all network paths.	Enrollment or coverage reports for non-privileged users, login flow configuration, and test records from sampled non-privileged accounts.	Enrollment is incomplete, with exceptions granted informally, or MFA applies only to remote users and not to in-office network access.

Evidence that passes an IA.L2-3.5.3 assessment

An assessor testing IA.L2-3.5.3 looks for proof that MFA is enforced on each access path, not just that a policy exists. The cards below cover the artifacts that usually carry that proof, and each one should be exported in final form, not as a working draft. Keeping them current between assessments is mostly a matter of scheduled exports tied to change records.

Privileged account list

The starting point for the assessment is a list of the accounts that hold privileged rights, such as domain administrators, cloud global administrators and local root or sudo users. SP 800-171A asks the organization to identify these accounts before testing MFA on them. Check that the list is pulled from the directory or identity platform, that each account has an owner, and that service accounts are classified correctly. Export it with a date and retain prior versions.

Identification and authentication procedures

Written procedures describe how users are enrolled in second factors, how lost tokens are replaced, and who approves exceptions. Assessors read these to confirm the MFA rules are documented and owned. Make sure the procedure names the identity platform, the enrollment steps and the approval path for any account that cannot use MFA. A draft policy does not satisfy the requirement until it is approved and in effect.

MFA enrollment and enforcement configuration

Export the authentication flow, policy or stage settings from the identity platform to show which factors are required and for which groups or applications. For example, a flow that runs an authenticator validation stage on every login shows enforcement, while a flow that only prompts users who enroll voluntarily does not. Confirm that privileged groups cannot bypass the stage and record the configuration version alongside the export.

Login audit records with second-factor challenges

Authentication logs that show a second-factor challenge for privileged and remote sessions give direct proof that enforcement works in practice. Pull a sample of successful and failed logins for each privileged account and for remote non-privileged access, and confirm that the factor type and result are recorded. Assessors often ask how long these logs are kept, so document the retention period in your system security plan.

Local and network access path evidence

MFA must cover local access to privileged accounts, network access to privileged accounts and network access to non-privileged accounts, so each path needs its own proof. Capture screenshots or exports from the console or SSH login, VPN or remote desktop gateway, and the cloud sign-in page for each path. Label every capture with the system name and date, and note which access paths were excluded and why.

Current access review

A recent access review shows that the people in the privileged account list are still authorized and that their second factors are still enrolled and valid. Record who reviewed the list, the date, the decisions made and the removals completed. Schedule the review on a fixed cadence set in your procedures, and attach the change tickets for revoked factors or accounts so the review can be traced back to action.

What the 5 and 3 point deductions mean for your POA&M

IA.L2-3.5.3 cannot be carried on a plan of action and milestones (POA&M), so any MFA gap has to be closed before the assessment. Under 32 CFR 170.24, the scoring methodology subtracts 5 points if multifactor authentication is not implemented for any users, and 3 points if it covers only remote and privileged users. Both values are greater than 1 point, and 32 CFR 170.21(a)(2) allows a POA&M only for requirements worth 1 point. A requirement that is not MET therefore leaves the score exposed to the full deduction, and you cannot defer the fix while you wait for a later review.

The 3-point case is the one teams underestimate. Having MFA on remote access and privileged accounts can look like full coverage, but the requirement also reaches local access to privileged accounts and network access to non-privileged accounts, which SP 800-171A treats as separate assessment objectives. Confirm each objective against your own system inventory: list every privileged account, every local and network logon path to CUI systems, and whether each path enforces a second factor. Interactive logons to servers, hypervisors and network devices are common gaps.

Do not model your score from a summary. Work through the eCFR text of 32 CFR 170.24 directly, and build your scoring worksheet from the account lists and authentication configuration you can produce as evidence. Ask whether any mobile devices reach CUI systems, because the CMMC Assessment Guide Level 2 expects MFA in that case too. If the result shows a gap, decide early whether internal staff or an outside implementation partner will configure the second factor, since the organization still owns the control and only an independent assessor can issue the outcome.

How to roll out MFA across privileged and remote access

This sequence takes an organization from an unknown set of accounts and access paths to enforced multifactor authentication on every path IA.L2-3.5.3 covers, with records an assessor can check. Each step produces a document or test result that the next step depends on.

Inventory accounts and access paths
Start by listing every account on systems that store, process or transmit CUI, and mark which ones are privileged. Then map each access path: local console or keyboard access, network access to administrative interfaces, and network access for ordinary users, including remote sessions and VPN logins. Assessors begin with the list of privileged accounts, so the inventory must name each one, its owner and the systems it reaches. The step is done when every account and path has one row in a signed inventory that the system owner has reviewed.
Choose the central identity platform
Decide where authentication decisions will be made before enrolling anyone. A central identity provider, such as an LDAP directory with Kerberos, FreeIPA, Keycloak for single sign-on, or authentik for a validation stage in front of applications, lets one MFA policy cover many systems. Check whether each candidate supports the protocols your applications use, and confirm with the vendor any capability you depend on. The output is a short design record naming the platform, the systems that will authenticate through it, and the systems that cannot, which will need a separate compensating design.
Enroll second factors for each user group
Enroll at least one second factor for every privileged account and every user who connects over the network. Common choices include TOTP apps, WebAuthn or FIDO2 security keys and passkeys, and hardware OTP tokens for users who cannot carry a phone. Verify that enrollment is tied to the individual account and that recovery codes are issued and stored under the same protections as the account. The record is an enrollment report by account, showing the factor type and enrollment date, reviewed against the inventory from step one.
Enforce MFA on each path in order of risk
Turn on the second-factor requirement for privileged network access first, then local privileged access, then network access for non-privileged accounts. Ordering by risk puts the accounts with the most reach under control earliest, and it lets you fix policy gaps on a small group before the rest of the workforce depends on the change. Record the policy setting for each path, including any exceptions and who approved them. Exceptions that remain open after this step belong in a plan of action with a named owner, but for IA.L2-3.5.3 they cannot be deferred to a POA&M because the scoring rules make them a partial-credit failure.
Test local console and service paths
Test each path with a login attempt that a non-privileged user cannot pass. Include local console logins on servers and workstations, administrative web consoles, SSH or RDP sessions, and service or automation accounts that use interactive logon. Service accounts that cannot satisfy a human second factor need a documented alternative, such as restricted network origins or certificate-bound credentials, and that alternative should be confirmed with your assessor before you rely on it. The output is a test record for each path that shows the date, account tested, expected result and actual result.
Capture configuration and login evidence
Export the configuration that enforces MFA and collect login logs that show second-factor challenges succeeding and failing. Assessors may test the mechanisms that implement multifactor authentication, so keep the configuration baseline under change control and retain the logs under your audit retention rules. Pair each evidence item with the account inventory so the assessor can trace one privileged account from its listing to its enrollment, its enforced policy and a recorded login. When the package is final and reviewed, it becomes the evidence set for the four assessment objectives in NIST SP 800-171A.

Which self-hosted open-source platforms can produce MFA evidence

Multifactor authentication evidence for IA.L2-3.5.3 comes from the identity layer that every privileged and remote login passes through. The platforms below can enforce second factors in different places, so the choice depends on where your accounts live and which applications need to trust the login.

authentik (MIT)

authentik's authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Its configuration can show which factors are enforced for which users, which supports the assessor's check that MFA covers privileged accounts. Confirm which factor types your assessor accepts and whether SMS or email codes are acceptable under your own system security plan before you enroll users with them. The MIT license carries no copyleft obligation, but support and upgrade terms come from your partner or your own team.

FreeIPA (GPL-3.0-or-later)

FreeIPA supports two-factor authentication with HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server during migration, which helps when a legacy VPN or network appliance still authenticates against RADIUS. For IA.L2-3.5.3, the directory account records and token enrollment lists are the evidence an assessor will sample. Check how the GPL-3.0-or-later license applies to any modifications you distribute, and confirm with your counsel whether your delivery model triggers those obligations.

Keycloak (Apache-2.0)

Keycloak provides single sign-on, so users authenticate once with Keycloak rather than separately in each application, and it supports OpenID Connect, OAuth 2.0 and SAML 2.0. Placing MFA at the Keycloak realm means one enforcement point covers many applications, which makes the evidence easier to collect for network access to non-privileged accounts. Confirm that every application that handles CUI actually routes its login through Keycloak, because a local account on an application that bypasses it will fail the assessment objective for that access path. The Apache-2.0 license permits commercial use without copyleft conditions.

Zitadel as an identity broker (AGPL-3.0-only)

Zitadel acts as a central identity broker, so users sign in through external providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP, and applications trust only Zitadel. The MFA evidence then depends on whether the upstream provider enforces the second factor, so you must document that provider's configuration as part of your boundary. The AGPL-3.0-only license requires source disclosure for network-facing modifications, which matters if you customize the product for a hosted service. Confirm where MFA is actually enforced before you rely on Zitadel alone as the evidence source.

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

This table separates the cost components of meeting IA.L2-3.5.3 by whether they are one-time or recurring, who is paid for each, and what pushes the cost up. No figures are given because none were supplied for this requirement, so use the table to structure a written quote and to compare offers on the same components.

Cost component	One-time or recurring, and who is paid	What drives it up and how to keep it down
MFA tooling or licenses	Recurring if commercial, paid to the vendor. Self-hosted open-source MFA platforms can remove license spend but still carry hosting and support costs.	Driven up by per-user licensing and by add-on factors. Keep down by confirming which second factors the chosen platform supports natively, such as TOTP, WebAuthn or FIDO2, before buying.
Engineering time for enrollment and enforcement	One-time for initial rollout, paid to internal staff or an implementation partner. Some ongoing time recurs for onboarding new users.	Driven up by the number of applications that must sit behind MFA and by legacy systems that need custom integration. Keep down by using a central identity provider so applications share one login flow.
Privileged account identification	One-time, paid to internal staff. Assessors expect a documented list of privileged accounts, so this work is required for the 3.5.3 assessment objective on privileged access.	Driven up by unmanaged local administrator accounts and undocumented service accounts. Keep down by reconciling the account inventory against directory groups before enforcement begins.
Service accounts and non-interactive processes	One-time analysis, then recurring review. Paid to internal staff. Ask the partner how these are scoped and documented.	Driven up by large numbers of automated accounts that cannot complete an interactive second factor. Keep down by confirming with the assessor how these are treated and documenting any alternatives the organization uses.
Tokens and hardware security keys	One-time purchase per user or device, plus replacement stock over time. Paid to the hardware vendor or distributor.	Driven up by the number of privileged users and by lost or replaced keys. Keep down by standardizing on one approved token type and recording issuance and replacement in the evidence log.
Evidence upkeep	Recurring, paid to internal staff. Covers enrollment records, configuration exports and account reviews kept in final form.	Driven up by manual screenshots and unversioned configuration. Keep down by automating exports of MFA configuration and account lists so evidence stays current without rework.
External testing or readiness review	Optional and usually one-time per cycle, paid to a consultant or testing firm. Quote separately from implementation.	Driven up by the breadth of systems in scope and by unclear boundaries. Keep down by fixing the written scope before work starts and asking for deliverables that map to the four assessment objectives.
Assessor fees for a certification assessment	Recurring per assessment cycle, paid to the authorized or accredited C3PAO, not to an implementation partner. Confirm whether the assessment applies in your contract timeline.	Driven up by the size of the environment and the number of systems in scope. Keep down by reducing scope and confirming with the sponsor which assessment type applies.

Who owns MFA, who helps, and where the assessor stops

Your organization owns IA.L2-3.5.3 in full. No vendor or consultant can accept that responsibility on your behalf. Your team decides which accounts are privileged, which access paths must require a second factor, and what happens when a user cannot enroll. Those decisions belong in your system security plan and access policy, and they must match what the system actually does.

Account inventory: Maintain the list of privileged and non-privileged accounts that the assessment objectives for 3.5.3 ask you to identify first.
Policy and exceptions: Define where MFA applies, including local, network and remote access, and document any approved exceptions with an owner and review date.
Access reviews: Review enrollments and privileged account membership on a schedule you set, and keep the records.
Enrollment and recovery: Decide how users enroll factors, how lost devices are handled and who approves recovery.
Operating evidence: Keep configuration exports, login logs and review records in final form, since drafts do not count toward MET.

Before any assessment, confirm that each control you describe is one your own staff can demonstrate without the partner in the room.

Gaps that cause MFA findings and how to close them

Most IA.L2-3.5.3 findings do not come from a missing MFA product. They come from accounts, paths and records that sit outside the main login flow. Each card below names one gap, why an assessor will find it, and the change that closes it.

Service accounts that bypass MFA

Service accounts, scripts and automation often authenticate with static passwords or long-lived keys, so they never meet the second factor. An assessor testing privileged accounts will ask whether any account with administrative rights can log on without MFA. Build an inventory of non-interactive accounts, document why each cannot use MFA, and move interactive administrators to phishing-resistant factors. Confirm with your assessor how they expect non-interactive exceptions to be recorded.

Admin consoles outside the identity platform

Hypervisors, firewalls, database consoles and network device management pages often keep local accounts that skip the central identity provider. Local access to privileged accounts is one of the four objectives in NIST SP 800-171A for 3.5.3, so these consoles are in scope. Inventory every management interface, point it at the central identity service where the product supports it, and confirm MFA on any local account that must remain.

Remote access without second factors

VPN, remote desktop gateways and web portals sometimes accept a password alone, especially when they were configured before the MFA project started. Network access to both privileged and non-privileged accounts requires a second factor under 3.5.3, and the remote access requirements in AC.L2-3.1.12 to 3.1.15 depend on it. Test each remote entry point with a non-privileged account, not only with an administrator, and keep the test results as evidence.

Mobile access to CUI systems left out of scope

Teams often treat phones and tablets as outside the boundary, then find that email, collaboration apps or CUI portals run on them. The CMMC Assessment Guide Level 2 states that MFA is required when a mobile device is used to access a system or application containing CUI. Add mobile access to the system security plan, list the apps and devices involved, and verify that each enforces a second factor.

Stale enrollments and unreviewed exceptions

Factors enrolled by departed staff, shared hardware tokens and exception lists that nobody reviews all weaken the control over time. Assessors look for current records that match the account list, so a stale token attached to an active administrator is a finding even when the policy is correct. Set a recurring review of enrolled factors against the account list, remove factors when people leave or change roles, and record each approved exception with an owner and an end date.

Evidence captured as drafts

Screenshots and configuration exports taken while a rollout is still in progress often show a policy that later changed, or no longer reflects the running system. Under 32 CFR 170.24(b), a requirement is MET only when evidence is in final form, and draft evidence does not count. Export the MFA policy, enrollment reports and identity provider settings after the final configuration is locked, date them, and store them with the system security plan. Ask your assessor which evidence formats they accept.

How long MFA takes, what it costs and whether to hire help

How much effort does multifactor authentication take to implement?

The effort depends on how many systems, accounts and access paths need MFA, and on whether an identity provider already exists. The work usually falls into four parts: identifying which accounts are privileged, choosing a second factor, enrolling users and enforcing MFA on each access path (local console, network access to privileged accounts, and network access to non-privileged accounts). SP 800-171A breaks 3.5.3 into four assessment objectives, so each objective needs its own evidence. Effort rises with the number of legacy applications that cannot call a central login, with remote and mobile access paths, and with the number of users who need hardware tokens or help enrolling. Ask any partner to show how it will count access paths before estimating hours.

Can our internal team implement MFA without an outside partner?

Yes, many internal teams can, provided they have engineers who understand identity, directory services and the access paths in scope. The harder part is usually evidence. An assessor will expect a list of privileged accounts, configuration showing MFA enforced on each path, enrollment records and audit records showing the control operates. Teams that already run an identity provider and document their access paths usually need less outside help. Teams that must also prepare an assessment package, or that lack staff to run a project alongside daily operations, often bring in a partner for the build, the documentation or both. The organization remains responsible for the control either way.

What does a partner need from our organization to start MFA work?

A partner needs enough information to draw the boundary and write a fixed scope. Expect requests for an inventory of systems that hold or process CUI, the directory and identity sources in use, the list of privileged and non-privileged account types, the remote access and VPN paths, and any mobile devices that reach CUI systems. The CMMC Assessment Guide Level 2 notes that MFA is required when a mobile device accesses a system or application containing CUI, so mobile access must be listed. Access to administrators who can approve design decisions, change windows for rollout and a named owner for the control also shorten the work. Missing inputs usually become change requests later, which affects both cost and timing.

How long does an MFA project take, and what sets the schedule?

The schedule depends on the written scope, and no fixed duration applies to every environment. Timing is driven by the number of access paths, the maturity of the existing identity system, the number of applications that need integration, the number of users to enroll, and the testing and change control windows the organization requires. Projects that rely on a single central identity provider with existing MFA support generally move faster than projects that must integrate many standalone applications. Ask for milestones tied to specific access paths, and for a clear statement of what the client must provide and when.

Can MFA go on a POA&M if it is not finished?

Generally no. Under 32 CFR 170.24, IA.L2-3.5.3 is one of two Level 2 requirements scored with partial credit: 5 points are subtracted if MFA is not implemented for any users, and 3 points if it covers only remote and privileged users. Because either value exceeds 1 point, 32 CFR 170.21(a)(2) does not allow it on a plan of action and milestones. Organizations should treat MFA coverage as a requirement to complete before the assessment rather than a gap to carry forward. Confirm the current rule text in the eCFR before making contract decisions, since the timing of Level 2 assessments is under review.

How does MFA relate to replay-resistant authentication?

They address different risks, and assessors test them separately. MFA (IA.L2-3.5.3) requires a second factor on specified access paths. Replay-resistant authentication (IA.L2-3.5.4) requires that captured login information cannot simply be reused, for example through challenge-response or ticket-based protocols. Some factors, such as phishing-resistant FIDO2 passkeys, can satisfy both in practice, but a factor that is accepted for MFA does not automatically satisfy 3.5.4. Plan both requirements together so that the chosen protocols and factors are documented against each control ID. Confirm with the assessment objectives in SP 800-171A how each one will be evidenced.

What does the Phase II suspension mean for MFA timing?

The suspension changes when certification may be required, not what the requirement asks for. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Because the CMMC Level 2 requirements still follow NIST SP 800-171 Rev. 2, MFA on privileged and remote access remains a control that contracts and SPRS scores depend on. Check the current status on the DoW CIO page, since its guidance has changed in recent months.

What should we ask for in a quote for MFA work?

Ask for a written scope that lists each access path, each system and each user group in scope, plus the four assessment objectives for IA.L2-3.5.3 that the work will evidence. Request separate line items for one-time work (design, integration, enrollment, documentation) and recurring work (token replacement, support, reviews), and ask which costs are fixed and which change with scope. Confirm what the client must provide, who signs off on acceptance, what evidence package is delivered, and how changes to scope are priced. Make clear that the partner prepares systems and evidence, while only an independent assessor can issue a certification.

How DeployOpen scopes and prepares MFA evidence

DeployOpen plans, implements and documents multifactor authentication for IA.L2-3.5.3 inside your own infrastructure, using self-hosted open-source identity platforms. 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

Agree in writing which privileged and non-privileged accounts, local and network access paths, and applications fall under the MFA requirement.
Confirm the list of privileged accounts with your team, since the assessment objectives depend on identifying them first.
Record which remote access and mobile device paths to CUI systems need MFA, and where the scope excludes them.

How we build

Configure the chosen identity platform, such as authentik, FreeIPA or Keycloak, with enrolled second factors for each in-scope account group.
Enforce MFA for local logon to privileged accounts, network access to privileged accounts and network access to non-privileged accounts.
Test the MFA mechanisms directly, including enrollment, failed factor handling and recovery code use, and keep the results as records.

How we hand over

Deliver configuration exports, account lists and test records that map to the four assessment objectives in NIST SP 800-171A.
Document the MFA procedure, enrollment steps and recovery process in a form your staff can operate after handover.
Walk your assessment team through the evidence so the final versions are ready for review, with drafts clearly separated.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is delivered.
Review MFA configuration when identity platforms are upgraded or when new applications join the CUI environment.
Confirm with your assessor or C3PAO which evidence formats they accept before the assessment is scheduled.