03.05.03 Multi-factor authentication: requirements and evidence

What 03.05.03 multi-factor authentication requires in SP 800-171 Rev. 3

03.05.03 requires multi-factor authentication for access to both privileged and non-privileged accounts. When a contract or CMMC assessment asks for proof that MFA covers accounts, the assessor will check two things: that a second factor is enforced for every account type in scope, and that you can show the configuration and records that prove it. The most significant Rev. 3 change is applicability. NIST's change analysis records that Rev. 3 applies multi-factor authentication to all system accounts, so a configuration that protected only administrators or remote users no longer matches the requirement. Its Rev. 2 counterpart, 3.5.3, is the one that carries weight in DoD scoring. CMMC Level 2 still assesses Rev. 2, and the scoring method gives 3.5.3 five points when MFA covers all accounts but only three points when it covers remote and privileged users alone. Because 32 CFR 170.21 does not allow that requirement on a plan of action and milestones for Conditional status, a gap here can affect your eligibility, not just your score.

The source controls, IA-2(1) and IA-2(2) in SP 800-53 Rev. 5, separate the two account populations. In plain terms, one covers multi-factor authentication for privileged accounts and the other covers non-privileged accounts, and 03.05.03 requires both. Expect three difficulties. Legacy applications often accept only a password and cannot call your identity provider, so they need a gateway, a federation change or a documented plan to retire them. Service accounts and automation identities cannot type a one-time code, so you must decide how they authenticate, such as certificates or tightly restricted credentials, and document that choice. Recovery paths are the quietest gap: if help-desk resets or backup codes bypass the second factor, an assessor will ask how those paths are controlled. Confirm each of these against your own system inventory before the assessment begins.

Which accounts and systems MFA must cover in a CUI environment

Multi-factor authentication under 03.05.03 is only as complete as the account inventory behind it. The cards below cover the scoping decisions that most often change the work, from the CUI boundary to accounts that nobody thinks of as users. Rev. 3 applies the requirement to all system accounts, so the scope should be settled early and confirmed in writing.

CUI systems and the boundary

Start with the system security plan and the boundary around every system that stores, processes or transmits CUI. Accounts that can reach that boundary, including those on connected corporate directories, are in scope for 03.05.03 even when the account owner never opens a CUI file. Document which identity sources feed the CUI enclave, because a single directory that authenticates both CUI and non-CUI systems changes the scope of every factor you enforce. Confirm the boundary with your federal sponsor before you configure anything.

Privileged and non-privileged accounts

The requirement covers access to both privileged and non-privileged accounts, so the scope is not limited to administrators. Separate the account inventory into administrative roles, standard user roles and service identities, then confirm that each group has a factor enforced at sign-in. Privileged accounts are usually the first gap auditors check, but a non-privileged account that reaches CUI through a shared application is equally in scope. Record the enforcement method for each group in the assessment evidence.

Remote access paths

Every route into the CUI environment is an access path that needs a second factor, including VPN gateways, remote desktop brokers, bastion hosts and web portals. A common gap is a remote path that uses a separate local login, which bypasses the central identity provider and its factor policy. Inventory each path, test sign-in on each one, and capture the configuration that enforces the factor. Vendor remote access tools deserve the same review as internal ones.

Applications with local passwords

Applications that keep their own user database, such as older internal tools, appliance consoles and some line-of-business software, often sit outside central single sign-on. Each one needs either a brokered login through a central identity provider or a documented compensating approach that your assessor accepts. Ask the application owner whether the product supports federated login before assuming it cannot. Where it cannot, record the limitation, the account count and the plan to replace or front the application in your plan of action.

Service and break-glass accounts

Service accounts and emergency break-glass accounts are the cases teams most often exclude by assumption. Rev. 3 applies multi-factor authentication to all system accounts, so each of these must be assessed rather than assumed out of scope. Where a service account cannot perform an interactive factor, document how it is restricted instead, and confirm that approach with your assessor and federal sponsor. Break-glass accounts should be tested on a schedule so the factor path works during an outage.

Third-party administrators

Managed service providers, vendor support engineers and contractors who administer CUI systems authenticate under your scope, even when their accounts live in the provider's tenant. Require that each external administrator signs in through an identity path you control or that the provider's factor meets your documented requirement. Review how vendor accounts are provisioned, reviewed and removed, and make sure the contract or agreement states the factor expectation. Ask the provider for its own evidence of enforcement.

How to roll out MFA across CUI systems step by step

This sequence takes an organization from an unknown set of accounts and login paths to multi-factor authentication enforced on every account that can reach systems holding CUI, with the records an assessor will ask to see at each stage.

Inventory accounts and login paths
Start by listing every account type that can reach a system holding CUI: named user accounts, privileged administrator accounts, service and shared accounts, and contractor or vendor accounts. For each account type, record every path it uses to sign in, including the VPN, remote desktop, web applications, command-line access, email and any direct logins to individual servers or databases. The owner of this step is usually the identity or platform team working with the system security plan owner. It is done when the inventory covers every system boundary in scope and an owner is named for each path. Keep this inventory as evidence, since the assessor will compare it against the accounts actually present in your directory.
Choose the second factor types
Decide which factor types the organization will accept for each account class and document why. Consider TOTP apps, WebAuthn or FIDO2 hardware keys, push approval and recovery codes, and confirm whether any SMS or email code option is acceptable under your own policy and the system security plan. Account for users who cannot carry a phone or who work in restricted environments, and for service accounts that cannot answer a prompt, since those need a different control design that should be recorded as an exception. The output is a factor decision record approved by the security owner, with the rationale for each choice. Confirm the approved factor list with your assessor before rollout so the record matches what they will test.
Route logins through one identity layer
Where possible, send applications and directory logins through a single identity provider rather than configuring MFA separately in each system. Open-source options such as authentik, Keycloak and Zitadel can act as the central point for single sign-on, with FreeIPA handling directory identities and OTP tokens where it fits your environment. Applications that cannot use single sign-on still need MFA, so list them as separate paths with their own enforcement method. The output is an architecture diagram showing each login path and the identity service that enforces the second factor on it. Confirm with each product's documentation that the protocol and factor types you chose are supported in your version before you commit to the design.
Enforce MFA on privileged accounts first
Turn on enforcement for administrator, root, domain admin and other privileged accounts before touching standard user accounts. Privileged accounts carry the highest risk to CUI, and enforcing them first lets the team fix configuration problems on a small, well-understood population. Configure the authenticator validation stage or equivalent policy so that no privileged session can complete without a verified second factor, then test each privileged login path from the inventory. The check that closes this step is a test log showing an attempt with only a password being refused for every privileged path, along with a successful login using the second factor. Save these results and the configuration export as evidence.
Extend MFA to all accounts
After privileged enforcement is verified, apply the same control to all non-privileged accounts that can access systems with CUI. The 03.05.03 requirement was made applicable to all system accounts in Rev. 3, so non-privileged users and service or shared accounts must be accounted for, either with a second factor or with a documented, approved design for accounts that cannot use one. Roll out in waves, tracking enrollment progress by group, and block access for users who have not enrolled within the grace period your policy sets. The output is an enrollment report by account type and a list of any accounts still outside enforcement, each with an owner and an approved exception.
Handle exceptions and recovery
Define how lost devices, changed phones, locked-out users and broken hardware keys are handled, because weak recovery paths can undo the control. Recovery should require a verified identity check through a defined process, issue a new factor, and generate an audit record. Document each exception, such as a legacy system that cannot support a second factor, with its compensating controls and a named approver, and track it so it can be reviewed and closed. Test the recovery process with a sample case to confirm it works and that the audit trail records the event. Keep the exception register and the recovery test record with the rest of the evidence set.
Document settings and retest
Export and version-control the configuration of every identity service, factor policy and enforcement rule, then record the baseline in the system security plan. Run the enforcement tests from earlier steps again on a schedule and after any change to the identity layer or to accounts in scope, and keep the results. Ask an independent assessor to examine the policy, interview the people who administer accounts, and test a sample of logins against the 03.05.03 assessment procedure. The output is a baseline configuration file, a dated test log and a current exception register that together show the control operating as described.

How an assessor tests 03.05.03 and what they ask for

This table maps how SP 800-171A Rev. 3 tests 03.05.03 across examine, interview and test methods, and what each method asks the organization to show. Read it as a checklist of the evidence to have ready before an assessor arrives, since the same objects are examined from several angles.

Assessment element	What the assessor checks	Evidence to have ready	Where it commonly fails
Determination statements	Two statements: MFA is implemented for privileged accounts and for non-privileged accounts	A written scope of which account types MFA covers, mapped to both statements	Scope is stated for admin accounts only, leaving standard user accounts out
Examine: policy and procedures	Identification and authentication policy and the procedures that put MFA into practice	Current IA policy and procedures with owners, approval dates and review cycle	Policy says MFA is required but procedures do not describe enrollment or exceptions
Examine: system design documentation	How MFA is positioned in the architecture for each access path	Diagrams showing every login path, including VPN, SSO, direct console and API access	Design shows MFA on the web portal but not on legacy protocols or service consoles
Examine: list of system accounts	Whether each privileged and non-privileged account is classified and linked to an MFA requirement	Account inventory with type, owner and MFA status, exported from the directory	Shared or service accounts appear with no MFA status or justification
Examine: system configuration settings	Enforcement settings in the identity provider, access gateway and applications	Exported policy or configuration showing MFA enforced per group, app or path	Settings enable MFA as optional, or a bypass rule overrides enforcement
Examine: system audit records	Evidence that MFA challenges happen and that logins succeed or fail as configured	Sample authentication logs showing second-factor events for both account types	Logs record password logins with no second-factor event for some applications
Interview: system operations personnel	How MFA is kept working day to day and what happens when it fails	Staff can explain outage handling and the approved fallback path	Operators describe a local bypass used during outages that is not documented
Interview: account management personnel	How MFA enrollment and exceptions are granted, reviewed and removed	Enrollment steps, exception approvals and periodic review records	Exceptions granted by email with no expiry or review date
Interview: information security personnel	How enforcement is monitored and gaps are found	Monitoring reports or alerts for accounts without a second factor	Security staff cannot say who reviews MFA coverage or how often
Test: MFA mechanisms	Whether the MFA capability works as configured when an assessor attempts access	Test results from supervised logins for each access path and account type	A path that accepts a password alone is found during testing, even though policy says otherwise

Choosing an open-source identity platform for MFA

authentik is best understood as an identity provider with an authenticator validation stage that runs during login. When a user signs in, the flow checks the second factors that user has enrolled, so the same enforcement point can cover applications that rely on it for access. For 03.05.03, that means you can configure the flow so that a second factor is required for every account that reaches a protected application, and then examine the flow configuration as evidence.

Factor types checked: TOTP authenticator apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes.
Enforcement point: the validation stage sits in the login flow, so enforcement depends on how the flow is bound to applications and user groups.
Recovery codes: static recovery codes are a factor type, so decide whether they count as acceptable for privileged accounts and document that decision.
Vendor-hosted factors: Duo and SMS are integrations that rely on outside services, which adds third-party dependencies to your risk assessment.
Evidence: flow exports and enrollment reports show which accounts have second factors, which an assessor can sample.

Confirm which factor types your privileged and non-privileged users need, and check the authentik license terms (MIT) against your deployment model before rollout.

Evidence that passes a 03.05.03 assessment

An assessor testing 03.05.03 wants proof on three levels: the written policy, the configuration that enforces it, and the sign-in behavior that shows it working on every login path. The cards below cover each artifact, plus the upkeep that keeps them current between assessments, because a point-in-time screenshot rarely survives an interview.

MFA policy and procedure

The written policy states which accounts require a second factor, both privileged and non-privileged, and which accepted factor types apply. The procedure explains how users enroll factors, how help desk staff verify identity before resetting one, and who approves changes. Assessors compare this document with the live configuration, so every statement in it should match a setting an engineer can point to. Review it on a schedule and record the review date and approver.

Configuration exports per application

Export the authentication flow settings from each identity provider and each application that handles CUI, and confirm the second-factor stage is bound to the login path. For example, in authentik the authenticator validation stage must sit inside the flow that users actually traverse. Exports should show the enforced policy, not just the list of available factor types. Store exports with a timestamp and the system configuration version they came from.

Account listings with MFA status

A current listing of system accounts, showing whether each one has an enrolled second factor and which role it holds, lets an assessor check that privileged and non-privileged accounts are both covered. Pull the listing from the directory or identity provider rather than a spreadsheet maintained by hand. Reconcile it against the account management records so that service and shared accounts are either covered by an approved alternative or listed as exceptions.

Sign-in logs showing second-factor challenges

Authentication logs are the strongest evidence that the control operates, because they record a second-factor challenge at the moment of login. Sample successful and failed sign-ins for privileged accounts and confirm each one includes the factor step. Keep logs in a central store with retention set by your contractual and agency requirements, and confirm that the logs cannot be edited by the administrators whose activity they record.

Exception register with approvals

Some accounts, such as legacy service accounts or devices, may not support a second factor at the time of assessment. Each exception needs a written justification, a named risk owner, a compensating control, an expiry date and a signed approval. Assessors look for exceptions that are rare, time-limited and reviewed. An exception that has quietly become permanent is a finding, so review the register at each assessment cycle and close items as the underlying system changes.

Test results for each login path

Assessors use the test method for 03.05.03, so you need recorded results for every route into the system: web portals, APIs, remote access, administrative consoles and single sign-on handoffs to other applications. Test each path with a standard user and a privileged user, record the result, and retest after any change to the flow. A login path nobody tested is the most common gap between a configuration that looks correct and one that holds up under examination.

Keeping evidence current between assessments

Schedule exports of configuration, account listings and exception register on a fixed cadence, and store each run with a date and the name of the person who ran it. Tie configuration changes to change records so that every change to an authentication flow has an approval and a before and after export. Ask your implementation partner and your assessor to agree on the cadence and the evidence format in writing before work begins, since the cadence is a local decision, not a NIST requirement.

Why 3.5.3 earns partial credit in CMMC scoring

Requirement 3.5.3 is the Rev. 2 counterpart of 03.05.03, and in CMMC Level 2 it is assessed as IA.L2-3.5.3. It is one of the few practices that can earn partial credit. Under the 32 CFR 170.24 scoring methodology it is worth 5 points when multi-factor authentication covers both privileged and non-privileged access, and 3 points when it covers only remote and privileged users. That gap is the single most important scoping question for an identity team: if MFA is enforced on VPN and administrator accounts but not on internal application logins that touch CUI, the score drops. Confirm which population your MFA policy actually covers, check it against the identity provider's enforcement settings, and record the answer in the system security plan before anyone calculates a SPRS score.

The partial credit has a hard limit. Under 32 CFR 170.21, a practice that is not fully implemented cannot be carried on a plan of action and milestones to reach Conditional status, so 3.5.3 must be met in full before an assessment. Teams sometimes plan to close a gap for non-privileged users after the assessment. That plan does not work for this requirement. Treat the full population of accounts that access CUI as the target from the start, and plan the rollout so that every account type is enrolled before the assessment date.

Confirm the version your contract requires before you invest in either baseline. DoW Class Deviation 2026-O0025, Revision 3 has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly, and a proposed FAR overhaul would require SP 800-171 Rev. 3 with ODP values published by the DoW CIO. The proposed rule was not final as of October 2026. Ask your contracting officer which revision applies to your agreement, and whether any ODP values for 03.05.03 have been assigned, so the identity design you build serves the version you will be measured against.

What meeting 03.05.03 costs in money and effort

This table lists the cost components of meeting 03.05.03 multi-factor authentication, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a request for quote, because the largest cost swings usually come from the number of applications and legacy systems rather than from the identity platform itself. No figures are given here, so ask each vendor and partner for a written scope before comparing totals.

Cost component	Who is paid or who bears it	One-time or recurring	Main cost drivers
Identity platform licenses	Commercial identity vendor, if chosen	Recurring, usually per user or per period	User count, premium factor or connector features, support tier
Self-hosting effort for the identity platform	Internal platform team or implementation partner	One-time build, then recurring operations	Number of environments, high availability design, patching cadence
Application integration engineering	Internal engineers or implementation partner	One-time per application, plus updates when apps change	Number of applications, legacy systems without modern protocols, custom login flows
Hardware security keys	Organization, through procurement	One-time per user or role, plus replacements	Number of privileged users, lost-key rate, FIDO2 versus other token types
Help-desk and account recovery procedures	Internal help desk and identity administrators	Recurring	Enrollment volume, recovery methods allowed, identity verification steps before reset
Evidence upkeep for 03.05.03	Compliance lead and system owners	Recurring, tied to each assessment cycle	Number of system accounts in scope, frequency of configuration changes, quality of logs
External testing or review	Independent testers or assessors, selected by the organization	Recurring at each testing or assessment cycle	Scope of account types, number of authentication paths, depth of testing requested
Assessor sampling effort	Independent assessor, paid by the organization	Recurring at each assessment	Sample sizes chosen by the assessor, number of accounts and applications sampled, readiness of evidence

Where MFA programs fail assessments

Most MFA gaps found in 03.05.03 assessments are not missing products. They are unmanaged paths around the second factor: legacy protocols, service accounts, weak factors, untested enforcement, recovery codes and exceptions nobody owns. Each card below names one gap and the action that closes it, so the assessor's examine, interview and test steps find the same answer the policy describes.

Legacy protocols that bypass MFA

Older mail clients, file transfer tools and directory binds often authenticate with a password alone and never present the second factor. Because 03.05.03 applies to access to both privileged and non-privileged accounts, an assessor who finds one working password-only path will record the requirement as not met, even if the browser login is protected. Inventory every protocol that reaches the system, then either disable the legacy method or route it through a broker that enforces the second factor. Test each path with a valid password and no token.

Service accounts without compensating controls

Service and integration accounts usually cannot answer a prompt, so teams exempt them from MFA and stop there. The assessment question is whether the exception is documented and controlled. Record each non-interactive account, its owner, where its credential lives, and the compensating control, such as a restricted source network, a certificate in place of a password, or a short-lived token. Confirm that interactive logins to these accounts are blocked, since a human using a service account is outside the exception.

SMS-only factors without a decision

SMS and email one-time codes are supported second factors in several identity products, but an assessor will ask why a weaker factor was chosen for a system that handles CUI. Where SMS remains, the closing action is a written risk decision that names the accounts affected, the threat accepted, the owner who approved it, and the date it will be reviewed. Offer phone-independent options such as TOTP apps, WebAuthn or FIDO2 passkeys, and confirm which factors your chosen identity platform actually enrolls and validates.

No evidence of enforcement testing

A policy stating that MFA is required is not evidence that it is enforced. Assessors test with the test method and examine configuration exports, so the organization needs repeatable proof. Run a scheduled test that attempts a password-only login to a sample of privileged and non-privileged accounts, and keep the results with the date, the account tested, the outcome and the ticket that fixed any failure. Keep the configuration export that shows the policy binding for each application.

Unmanaged recovery codes

Static recovery codes restore access when a phone or token is lost, and they can quietly defeat the second factor if they are generated once, stored in a shared document, or never revoked. Recovery must itself be verified, so issue codes only after an identity check, show them once, store them hashed, and expire or rotate them when the user re-enrolls a factor. Record who holds the codes for administrative accounts and how their use triggers an alert, since an assessor will ask how a recovery event is detected.

Exceptions without owners or expiry

Temporary exemptions for vendors, executives, break-glass accounts or legacy applications tend to outlive the reason they were granted. An exception register should list each exempted account or application, the business reason, the named owner, the compensating control, and an expiry date. Review the register on a fixed schedule and remove expired entries. If an exception cannot be justified in writing, the account must be enrolled before the next assessment, not documented as an open item.

Who does what for 03.05.03: your team, a partner and the assessor

Your organization is accountable for 03.05.03 whether or not anyone else touches the systems. Leadership must decide which accounts fall under the requirement, who approves exceptions, and which second factors are acceptable for the people who handle CUI. The requirement also covers all system accounts under Rev. 3, so the scope decision must include service and administrative accounts, not only staff logins. Your team keeps the authentication policy, the account inventory and the records of who was enrolled and when.

Scope decisions: Confirm which systems and account types must enforce a second factor, including privileged, non-privileged and service accounts.
Policy and exceptions: Write the authentication policy and approve any exceptions in writing with an owner and a review date.
Account and enrollment records: Keep the account inventory and enrollment history that an assessor will ask to see.
Staff interviews: Assessment objects include the people who run system operations, account management and information security, so those roles must be able to explain the control.
Final responsibility: Your organization signs off on the system security plan and any statements of compliance you make to a customer.

Before engaging anyone, check that a named owner can answer an assessor's questions about every account category in scope.

Common questions about 03.05.03 multi-factor authentication

Does NIST SP 800-171 Rev. 3 require MFA for every account?

Yes, 03.05.03 asks for multi-factor authentication on access to both privileged and non-privileged accounts, so the requirement is not limited to administrators. NIST's change analysis records that Rev. 3 changed the applicability of multi-factor authentication to all system accounts, which is a broader reach than many Rev. 2 implementations assumed. Under Rev. 2, the matching requirement 3.5.3 is scored in CMMC Level 2 at 5 points, or 3 points when MFA covers only remote and privileged users. Your assessor will look for a documented account inventory, so confirm early which accounts exist, including service and shared accounts, and how each one authenticates.

What drives the cost and time of adding MFA to our systems?

The main cost drivers are the number of systems that need MFA, how many of them already use a central identity provider, and whether applications accept a shared login or need separate integration. Costs are split between licenses or hosting for the identity platform, implementation labor, testing, and recurring administration such as enrollment support and token replacement. Ask any provider for a written scope that lists each application, the sign-in path it uses, the factors you will accept, and what is included in documentation and handover. Because no official effort figure is supplied for this requirement, treat any duration you are given as an estimate that depends on that inventory.

Can our in-house team implement MFA without outside help?

Often yes, if the team has experience with identity protocols and the applications involved. The work usually includes choosing an identity platform, integrating each application through OpenID Connect, OAuth 2.0 or SAML 2.0, enrolling factors, testing failure and recovery paths, and writing the procedures an assessor will ask to see. Teams that have not done this before tend to underestimate application integration and recovery procedures. Outside help is usually most useful for fixed-scope work such as integrating legacy applications, hardening the platform, or preparing the evidence set. DeployOpen implements self-hosted open-source platforms in your own environment and prepares evidence, but it does not assess or certify your compliance.

What do we need to provide before MFA work can start?

You need to supply access to the environment, a current list of systems and applications, the account types in use, and the people who approve access and own each system. You also need a decision on which factors are permitted, how users recover access when a device is lost, and who runs the help desk. Your existing system security plan, policies and identity documentation shorten the work because they show what is already defined. Confirm with your assessor which artifacts they expect, since they will test whether the configuration matches what you documented.

Are SMS codes an acceptable second factor under 03.05.03?

03.05.03 requires multi-factor authentication but does not name specific factor types, so the choice is yours to defend. SMS codes can be enabled in some platforms, including authentik, which can validate SMS codes among other second factors. Because SMS is widely considered weaker than app-based or hardware-backed factors, many organizations prefer TOTP apps, WebAuthn or FIDO2 passkeys, and treat SMS as a fallback. Document why each factor is accepted, check that your authenticator management and replay-resistance controls agree with that choice, and review the position with your assessor before you rely on it.

How should we handle service accounts and non-interactive logins?

Service accounts cannot complete an interactive second factor, so the usual approach is to remove them from interactive login where possible and protect them another way. Options include workload identity, certificate-based authentication, or restricting service credentials to specific hosts and network paths. Whichever method you choose, document it as part of your authentication design, since an assessor will look for how each non-interactive account meets the requirement. Map every service account in your inventory, record its owner, and confirm with your assessor how they will treat accounts that cannot use MFA before the assessment begins.

Does using an identity broker like Keycloak or Zitadel satisfy 03.05.03 by itself?

No. A central identity platform helps because MFA is enforced once for many applications, but the requirement still applies to every account that reaches your systems. Keycloak provides single sign-on and can broker logins to external identity providers, while Zitadel can act as a central identity broker for providers such as Microsoft Entra ID or Okta. Your job is to confirm that each application actually sends users through the central flow, that external providers enforce MFA for their own users, and that local accounts cannot bypass it. Record these paths in your design documentation so the examine and test steps can be completed.

How DeployOpen scopes and prepares MFA evidence

DeployOpen starts an MFA engagement by agreeing the scope in writing before any work begins. For 03.05.03 that scope has to name which accounts are covered, both privileged and non-privileged, and which systems and applications must sit behind the identity platform. Because Rev. 3 applies multi-factor authentication to all system accounts, the scope should list every account type in the system security plan, including service and administrative accounts, and state where any exception or compensating control is recorded. The organization owns the decision on what is in scope and owns the control itself. DeployOpen prepares the systems and the evidence and does not decide whether the requirement is met.

Implementation happens inside the client's own infrastructure, whether that is their cloud accounts, data centers or an air-gapped network. Depending on the agreed design, the identity layer may be built on authentik, which validates enrolled second factors such as TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS, email and static recovery codes during login, or on FreeIPA, which supports HOTP and TOTP tokens and can proxy OTP checks to an existing RADIUS server during migration. Keycloak or Zitadel may sit in front of applications so that each application does not handle MFA on its own. The team then tests every login path, including a failed second factor, a lost device, a recovery code and a privileged session, and records the results. Confirm with the platform vendor which factor types the chosen version supports and whether recovery codes meet your policy.

Evidence preparation focuses on what a assessor will examine and test. DeployOpen can export configuration settings, such as the MFA policy, the list of enrolled factors per account class, and the authentication flow bindings, and it can keep the system design documentation, the account list and the audit records that show MFA events. Those exports are prepared for the assessor to review and do not replace the organization's own policy or procedures. DeployOpen does not issue assessment results, scores or certifications. Independent assessors and the organization's own governance process reach those conclusions, and the organization is responsible for keeping its controls and evidence current after handover.