IA.L2-3.5.4 Replay-resistant authentication requirements

What IA.L2-3.5.4 replay-resistant authentication requires

If you are preparing for a CMMC Level 2 assessment, IA.L2-3.5.4 asks you to show that login information captured from the network cannot simply be played back to gain access. The requirement applies to network access for both privileged and non-privileged accounts. In practice, an assessor wants to see that the mechanisms you use to authenticate over the network are designed so that a captured exchange is useless the second time it is sent. A password sent in a form that can be copied and reused is the classic weakness this requirement is meant to close. The control is a question of how your authentication protocols work, not only whether users have passwords or multifactor prompts.

The replay attack works like this: an adversary records a valid login exchange on the wire, then resends it later to impersonate the user or service. Protocols that use fresh challenges, nonces, timestamps or time-limited tickets make a recorded exchange worthless. Requirement 3.5.4 is worth 1 point under the scoring methodology in 32 CFR 170.24, and because it is not on the exclusion list in 32 CFR 170.21, it can be placed on a plan of action and milestones for Conditional Level 2 status if your score is at least 88 of 110. That flexibility is useful, but it is a time-limited bridge with a closeout deadline of 180 days, not a permanent exemption, so confirm the current rule text and your score with your sponsor before you rely on it.

What usually makes this requirement hard is the environment, not the policy. Legacy protocols such as basic LDAP binds, older application logins, and network devices that accept plaintext credentials can all expose reusable login data. Mixed directories add to the difficulty, because a Windows domain, a Linux identity store and cloud applications may each handle sign-in differently. Start with an inventory of every network authentication path, including service accounts and management interfaces, and record which mechanism each one uses. Then identify the paths that rely on reusable credentials and decide whether to replace them, front them with a replay-resistant protocol such as Kerberos, or document a compensating approach that your assessor will accept.

Which accounts, networks and protocols fall under 3.5.4

The requirement reaches every network path that carries a login to a CUI system, so scoping starts with account lists and network maps, not with a product. The decisions below determine how many paths assessors test, which protocols must be replaced, and where a third party's logins fall into your evidence.

Privileged and non-privileged network access

Both account classes are in scope. The requirement names network access to privileged accounts and to non-privileged accounts, so an administrator console and a standard user's file share each need a replay-resistant path. Start by exporting the privileged account list and the non-privileged accounts that can reach CUI over the network. Effort grows with the number of distinct login paths rather than headcount, so count paths per system and note which ones already use a challenge-response or ticket exchange.

CUI systems and enclaves

Scope follows the CUI boundary. Every system that stores, processes or transmits CUI, plus the directory, jump hosts and security tools that authenticate people into it, belongs in the assessment. A narrow enclave with a single identity source usually means fewer login paths to test and fewer documents to explain. Confirm the boundary in the system security plan before you change any protocol, because a path left outside the documented boundary still draws questions when an assessor traces access to CUI.

Legacy protocols that send reusable credentials

Protocols that transmit a credential or a reusable response an adversary can capture and replay are the core concern of this requirement. The CMMC Assessment Guide for Level 2 explains that insecure protocols let an adversary capture login information and reuse it. Inventory older services, network appliances, printers, scanners and legacy applications that authenticate, and record which protocol each one uses. Each system that cannot move to a replay-resistant mechanism needs a documented decision and a compensating control, and this work is often the largest share of effort.

Kerberos and ticket-based directories

Ticket-based systems offer the most direct route to evidence for this requirement. The Assessment Guide cites Kerberos as an example of a protocol with built-in replay resistance, and FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos key distribution center. Confirm that clients, services and time synchronization are configured so tickets validate correctly, then capture the directory configuration as evidence. Mixed estates often keep a second, weaker bind path beside the ticket service, and that second path is what an assessor is likely to test.

Third-party and cloud identity services

A cloud directory or external identity provider that carries logins into your CUI environment remains part of your evidence, even though you do not operate it. Request the provider's documentation on the authentication protocols and token lifetimes it uses, and record whether they resist replay in your assessment file. Federated sign-in through SAML or OpenID Connect assertions also needs its signing, audience and lifetime settings checked on your side. Confirm these details with the provider in writing before you rely on them in your system security plan.

Service accounts and workload identities

Processes acting for users, scheduled jobs and workloads also authenticate to the network, and they are easy to overlook. A service that presents a long-lived password or static secret is a candidate for replay exposure. Certificate-based identities are one option: the OpenBao PKI secrets engine issues X.509 certificates without manual key and signing request handling, and cert-manager renews TLS certificates for Kubernetes or OpenShift workloads before they expire. Inventory service accounts separately from people, since they often fall outside the regular user review.

How an assessor tests replay resistance

This table walks through how an assessor reads IA.L2-3.5.4 against NIST SP 800-171A, what evidence they request, how they test it, and where implementations usually fall short. Use it to prepare evidence before the assessment rather than after a finding is written.

Assessment element	What the assessor checks	Common finding to avoid
Assessment objective	Replay-resistant authentication mechanisms are implemented for network access to privileged accounts and for network access to non-privileged accounts. The single objective covers both account types.	Evidence that covers only administrator accounts, leaving standard user access unaddressed.
Mechanisms in scope	The authentication protocols that carry logon for network access, such as Kerberos tickets or challenge-response exchanges, and the systems that rely on them.	Legacy protocols that send reusable credentials across the network with no replay protection.
Identification and authentication procedures	Documented procedures that name the approved mechanisms and state which systems must use them.	Procedures that describe intent but do not match the configured systems.
List of privileged system accounts	A current list showing which accounts are privileged and proof that their network logon uses a replay-resistant mechanism.	A privileged account list that is out of date or omits service and break-glass accounts.
Audit records and tests	Logs or test results showing successful replay-resistant logons and the assessor's own test of the mechanism where feasible.	No logs or test records, so the mechanism is described but never shown working.
Coverage across accounts	Whether the same mechanism applies to every account type that uses network access, including non-privileged users.	A mechanism applied to some directories or applications but bypassed by others.
Final-form evidence	Evidence in final form that reflects the current configuration at assessment time, not drafts or planned changes.	Drafts or design documents presented as proof of implementation.

Why captured login information can be reused

An authentication exchange is only as safe as the material that crosses the network. If a login protocol sends a reusable credential or a fixed response that an attacker can observe, the attacker does not need to know the password. They can record the exchange on a compromised host, a shared network segment or an unencrypted path, then present the captured information to the server later and be accepted as the legitimate user. The CMMC Assessment Guide for Level 2 explains this risk in terms of insecure protocols that let an adversary capture login information and reuse it. IA.L2-3.5.4 exists to close that gap for network access to both privileged and non-privileged accounts.

Replay resistance comes from making each captured exchange worthless the moment it is replayed. In a challenge-response design, the server sends a fresh, unpredictable challenge for every login, and the client proves knowledge of the secret by answering that specific challenge, so an old answer does not match a new one. In a ticket-based design, such as the Kerberos model the Assessment Guide cites as having built-in replay resistance, the client obtains time-limited tickets from a trusted key distribution center and uses them with timestamps and session keys, so a captured ticket fails outside its validity window or without the session key. Neither design requires the attacker to break the cryptography, which is why assessors look at the protocol in use rather than only at password rules.

For the reader, the practical decision is which protocols carry network logon for each account class, and whether any of them can still be downgraded to a method that is not replay resistant. Confirm with your identity team which protocols are enabled on domain controllers, VPN concentrators, web applications and administrative jump hosts, and whether legacy clients can still negotiate weaker mechanisms. Records of those settings, plus the list of privileged system accounts, are the kind of evidence an assessor will ask to see when testing this requirement.

How to implement replay-resistant authentication step by step

This sequence moves an organization from an unknown mix of login methods to a documented set of replay-resistant authentication paths for privileged and non-privileged network access, with evidence an assessor can test against IA.L2-3.5.4.

Inventory every network authentication path
Start by listing every way a user, process or service authenticates to reach systems that handle CUI. Cover VPN, remote desktop, SSH, directory binds, web applications, APIs, service accounts and administrative consoles, and mark each path as serving a privileged or non-privileged account. The output is an authentication inventory with one row per path, its protocol, its account type and its owner. Assessors use this list to confirm that no network path has been left out, so confirm it with the system administrators who actually operate each path rather than relying only on the architecture diagram.
Identify replayable protocols and captured credentials
Review each row of the inventory and flag paths where a captured login could be reused, such as schemes that send a reusable password or bearer value without a fresh challenge, a nonce or a time-bound ticket. The CMMC Assessment Guide Level 2 explains this risk, using Kerberos as an example of a protocol with built-in replay resistance. The output is a short list of flagged paths with the reason for each flag. Record the protocol versions in use, because a path may be replay-resistant in one configuration and not in another.
Select a replay-resistant mechanism for each path
For each flagged or in-scope path, choose a mechanism that resists replay, such as a challenge-response scheme or a ticket-based protocol like Kerberos, or a federated sign-in that relies on signed, short-lived assertions. Document the chosen mechanism, the reason it fits the path and any dependency it creates. Confirm with each platform vendor that the chosen mechanism is supported in your version and configuration, because not every product supports every protocol. The output is a mechanism decision record for each path that an assessor can read alongside the system security plan.
Integrate applications and directories with the chosen mechanism
Connect applications and directories to the selected authentication source so that sign-in for privileged and non-privileged accounts uses the replay-resistant path. Open-source identity providers such as authentik can broker sign-in for applications over supported protocols, and FreeIPA can provide Kerberos single sign-on for Linux and UNIX hosts through an MIT Kerberos KDC. Where a service needs machine identity, certificates from a PKI engine or cert-manager can support mutual TLS. The output is a configuration baseline for each integration, stored under change control.
Retire or isolate replayable methods
Disable the legacy or replayable login methods that the inventory flagged, or restrict them to a documented exception with compensating controls. Remove direct password bind paths where a federated or Kerberos path now exists, and confirm that local fallback accounts are limited and monitored. Record each retirement with the date, the change ticket and the person who approved it. The output is a list of disabled methods and any approved exceptions, which assessors will compare against the original inventory to test whether replayable access truly ended.
Test the mechanisms against the assessment objective
Test each path the way an assessor would: attempt sign-in through the replay-resistant mechanism for a privileged and a non-privileged account, confirm that the identity provider or KDC logs the event, and confirm that the flagged legacy method no longer grants network access. Keep the test scripts, the timestamps and the audit records. SP 800-171A assesses this requirement with one objective, so test results should show that the mechanism is implemented for both account types. The output is a dated test record with pass or fail results and remediation tickets for any failure.
Document the evidence and maintain it
Assemble the final evidence package: the authentication inventory, the mechanism decision records, configuration baselines, retirement records, test results and the audit log extracts that show the mechanisms in use. Place the package where the system security plan references it, and set an owner to review the inventory whenever a new path, application or directory is added. Assessors accept evidence in final form only, so drafts and unsigned records should be finalized before the assessment. The output is a controlled evidence set that a qualified assessor can trace from requirement to configuration to test result.

Evidence that satisfies 3.5.4 and how to keep it current

An assessor testing IA.L2-3.5.4 looks for proof that replay-resistant mechanisms are in place for network access to both privileged and non-privileged accounts, and that the proof is in final form. The cards below cover the artifacts that carry that proof and how to refresh each one between assessments so it stays current.

Authentication configuration exports

Export the live configuration of every identity provider, directory and gateway that handles network sign-in, such as the authentik providers, FreeIPA Kerberos settings and any VPN or remote access gateway. Each export should show which protocol carries the login, so an assessor can see challenge-response or ticket-based exchange rather than a plain credential transmitted per request. Date each export and store it under change control, because a configuration captured months earlier may no longer reflect the running system.

Protocol settings showing replay resistance

Document the specific protocols that provide replay resistance, such as Kerberos tickets issued by a KDC, and show where they are enforced. The CMMC Assessment Guide uses Kerberos as its example of built-in replay resistance. Record the encryption types, ticket lifetimes and clock synchronization settings, since a skewed clock or weak settings can undermine the claim. Keep a dated record of who approved each setting.

Privileged and non-privileged account lists

Produce a current list of privileged system accounts and of standard user accounts that have network access, and show which authentication method applies to each group. SP 800-171A names the list of privileged system accounts as potential evidence for 3.5.4, and the assessor uses it to confirm that both groups are covered. Reconcile the list against directory exports at each review, and retain the reconciled version as the record of the period.

Login audit records

Retain authentication logs that show successful and failed network logins for privileged and non-privileged accounts, with timestamps and the protocol or method used. These records let an assessor test the mechanism in operation, not only in design. Confirm that logs from the identity provider, KDC and remote access gateways are forwarded to a central store and that retention meets the period your contract and system security plan require.

Certificate lifecycle records

Where certificate-based authentication or TLS is part of the sign-in path, keep records of certificate issuance, renewal and revocation. Tools such as OpenBao's PKI secrets engine and cert-manager renew certificates automatically, so the evidence is the issuance log and issuer configuration rather than manual approvals. Check that renewal events appear in your logs, since an expired certificate can stop logins and create an unplanned gap in evidence.

Refreshing evidence between assessments

Assign an owner and a fixed review cadence to each artifact above, and mark every version as final once it is approved, dated and stored. Drafts and unsigned exports do not count toward a MET determination, so avoid leaving working copies as the only record. Before any assessment or affirmation, re-run the exports, confirm they match the running system, and record any change in your change management log. Ask your assessor early which format they expect.

Open-source options for replay-resistant sign-in

authentik is an identity provider that applications delegate sign-in to. It supports OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so an application that federates through it does not hold its own login logic. For IA.L2-3.5.4, the question is whether the protocol used for each network sign-in path resists replay. Token-based flows such as OpenID Connect and SAML assertions with validity windows and signature checks are the usual evidence, but you must confirm for each application which flow it actually uses.

Protocol inventory: List every application, the provider type it uses and whether it signs in through a token flow or a legacy method.
Legacy paths: Identify LDAP binds, RADIUS or direct password forms that bypass federation, since these are the paths an assessor will examine first.
Configuration evidence: Export provider settings, token lifetimes and signing configuration as dated records.
License: authentik is MIT licensed, which generally permits internal use, but confirm the terms that apply to your build and any bundled components.

Confirm with your assessor which provider types and protocols they will accept as replay-resistant for your environment before you design the flow.

What meeting 3.5.4 costs in money and effort

This table breaks down the cost components of meeting IA.L2-3.5.4 by who is paid, whether each cost is one-time or recurring, and what moves it up or down. No fee or duration is supplied for this requirement, so use the table to build the questions you put to each quote, and to see where self-hosted open source removes license spend.

Cost component	One-time or recurring	What drives it	Where open source changes the cost
Identity platform design and deployment	One-time	Number of identity sources, existing Kerberos or directory setup, and whether a new realm is needed	FreeIPA and authentik carry no license fee, but design and deployment labor still applies
Engineering to integrate applications	One-time, with recurring work for new apps	Count of applications that must use a replay-resistant method, and whether each supports Kerberos, OIDC or SAML	Removes license spend on connectors; integration hours remain and should be quoted per application
Certificate and key lifecycle setup	One-time setup, recurring renewal	Number of TLS workloads, Kubernetes or OpenShift use, and choice of issuer	cert-manager and OpenBao PKI avoid commercial certificate lifecycle licenses, but need staffed operation
Evidence collection and upkeep	Recurring	Frequency of configuration exports, access reviews, and log retention, plus the number of systems in scope	Self-hosted logs and configuration exports cost storage and staff time rather than vendor fees
External security testing	Recurring, usually periodic	Scope of network authentication paths tested, including Kerberos and token flows	Testing tools may be open source, but testers' time is a separate, quoted cost
Assessor sampling and assessment fees	Recurring per assessment cycle	How many systems and privileged accounts the assessor samples, and how clean the evidence is	Open source does not reduce assessor fees; clean, final-form evidence can reduce re-sampling
Remediation of gaps or a POA&M	One-time, if needed	Legacy protocols such as NTLM or plaintext-capable services that need replacement	Replacing legacy protocols may require new software; confirm the cost before planning a POA&M

Who owns replay-resistant authentication and who helps

Your organization owns the control. That means it decides which authentication mechanisms protect network access to privileged and non-privileged accounts, approves the design, accepts the residual risk and signs off on the evidence the assessment will review. An outside party can build or configure the mechanism, but it cannot make your access decisions for you.

Accountable owner: Name one person who answers for 3.5.4 in the System Security Plan and during the assessment.
Design decisions: Choose which protocols (for example, Kerberos-based single sign-on or ticket-based access) cover administrator and user logons, and document where any legacy protocol remains.
Account inventory: Maintain the list of privileged system accounts and confirm that each one is covered by the mechanism.
Final evidence: Collect configuration exports, logs and test records in final form, since drafts do not count toward a MET result.
Ongoing operation: Review exceptions and renew the mechanism's configuration as systems change.

Confirm that your internal owner can explain the design end to end without relying on the implementer.

Where organizations fall short on 3.5.4

Most shortfalls against IA.L2-3.5.4 are not missing products. They are legacy protocols left enabled beside stronger ones, partial coverage across account types, and no records that show the mechanism is working. Each card pairs one gap with the step that closes it, and the assessor checks the same objective either way.

Replayable protocols still enabled

Legacy challenge-response such as NTLM can remain available on servers and workstations long after a stronger protocol was deployed. A captured login exchange can then be reused, and the assessor will ask whether the replay-resistant mechanism is the one actually used for network access. Inventory which authentication protocols each system accepts, disable the replayable ones where the platform allows, and confirm the negotiated protocol in logs.

Mechanism covers only some accounts

The objective applies to network access for both privileged and non-privileged accounts. A directory-backed Kerberos setup often covers employees while local accounts, appliance logins or a legacy VPN still accept static credentials. Build a list of every network entry point, map each to the account types it accepts, and document any path that cannot use the mechanism.

Service accounts missing from scope

Service accounts, scheduled jobs and integration accounts often hold privileged rights but never appear in the privileged account list. They authenticate over the network with passwords that do not rotate, so they fall outside the review. Include every service account in the privileged list the assessor reviews, and confirm each one authenticates through a replay-resistant method or is documented with a compensating reason.

No audit records of the mechanism

An assessor tests whether the mechanism is implemented, and identification and authentication records, privileged account lists and audit records are the evidence named for this objective. Teams often configure a strong protocol and never export proof of it. Retain directory and authentication logs that show the protocol and account for each network logon, and keep the configuration exports dated and in final form.

Protocol choice left undocumented

Without a written decision, the mechanism in place depends on who configured the system. A short record that names the approved protocol for each system class, the owner and the review date lets an assessor match the design to the test results. Store this record in the system security plan and update it when a platform is added or upgraded.

Container and certificate workloads overlooked

Workloads that authenticate with TLS certificates or service tokens can bypass the directory and fall outside the review. Certificates that expire or are issued by hand also tend to be renewed late, leaving weak fallback logins in place. Confirm which internal services authenticate with certificates, that issuance and renewal are automated, and that each service is listed with its account type.

Questions buyers ask about IA.L2-3.5.4

Can we implement IA.L2-3.5.4 in-house without an outside firm?

Yes. The organization owns its controls, so its own staff can design, configure and evidence IA.L2-3.5.4 without an outside firm. The question is whether the team already runs a central identity source and a replay-resistant protocol for network sign-in to both privileged and non-privileged accounts. Teams that run Active Directory with Kerberos, or a central identity provider with strong protocol support, usually have most of the mechanism in place and need to confirm coverage across every access path. Teams without central identity often need to design it first. Outside help is most useful when internal staff lack protocol experience or time, or when the work spans many systems. Whatever the choice, the assessor who tests the requirement must be independent of the team that built it, and the organization remains responsible for the result.

How much effort does replay-resistant authentication take, and what drives it?

Effort scales with the number of network access paths and identity sources, not with the requirement text, which has a single assessment objective. Start by listing every route into the environment: VPN, remote desktop, SSH, web consoles, cloud administration portals and network devices. Then check whether each route uses a challenge-response or ticket-based method, or still relies on protocols that let captured credentials be reused. The main cost components are staff time for design, configuration and testing, licensing if you buy commercial identity products, and any implementation partner fees under a written, fixed-scope agreement. Design, migration and testing are one-time work. Account reviews, certificate renewal and evidence refresh recur each cycle. Ask any quote to break out each access path, each identity source and the recurring work separately.

How long does IA.L2-3.5.4 take to complete?

No duration for this work is supplied here, so treat any timeline as something to confirm with the people doing the work. The sequence drives the schedule: inventory access paths, choose the mechanism for each, configure and test it, then collect evidence in final form. Evidence in draft form does not count toward a requirement being met, so plan time for review and sign-off. Timelines also depend on change windows for production systems, the number of legacy applications that need protocol changes, and whether a directory or federation migration must come first. Ask any partner for a timeline tied to a written scope, with each access path listed as its own milestone. Confirm with your assessor or the current DoW CIO guidance which assessment schedule applies to your contract.

What does the 3.5.4 work need from our internal team?

Expect to need five kinds of people: an identity owner who controls the directory or identity provider, administrators for each system that accepts network sign-in, a security reviewer who checks the configuration against the assessment objective, someone who maintains the list of privileged accounts, and a records owner for audit logs that show the mechanism working. The assessment objective is tested through identification and authentication procedures, the list of privileged accounts, audit records and tests of the mechanisms themselves, so each of these needs a named owner. Plan for change windows on production systems and for time to retire or replace protocols that cannot resist replay. Your team also needs to approve which mechanism each access path uses, because that decision stays with the organization.

Can IA.L2-3.5.4 go on a POA&M, and what is the 180-day rule?

Possibly. Under 32 CFR 170.24, IA.L2-3.5.4 is worth 1 point, and it is not on the exclusion list in 32 CFR 170.21, so it can go on a plan of action and milestones for Conditional Level 2 status. The rule allows this only when the overall score is at least 88 out of 110, which the rule expresses as 0.8. Closeout is due within 180 days. Check three things before relying on this. Confirm the current CMMC phase schedule with the Department of War, because the eCFR text and the DoW CIO page do not currently match. Confirm that your contract accepts a Conditional status. Treat the 180-day clock as a commitment you must meet with evidence in final form. A POA&M is a schedule for closing a gap, not a way to avoid meeting the requirement.

What can an implementation partner do for a CMMC assessment, and what can it not do?

A partner can prepare systems, configure the mechanism, write the procedures, build the account lists and collect evidence in the form an assessor reviews. It can also test the mechanism and report gaps before the assessment. A partner cannot issue an assessment report or certify your environment. Self-assessments remain the organization's own responsibility, and Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB. DeployOpen works this way: it implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for assessment. It does not issue audit reports, attestations or certifications. Scope, deliverables and timelines are agreed in writing before work starts.

Which open-source tools help meet replay-resistant authentication requirements?

Several self-hosted open-source components can produce the mechanism and its evidence, but none satisfies IA.L2-3.5.4 by installation alone. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, and the CMMC Assessment Guide cites Kerberos as an example of a protocol with built-in replay resistance. authentik acts as an identity provider through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it. Confirm for each protocol and provider you enable that it resists replay for the network access you use, then document that decision. For certificate-based designs, OpenBao's PKI secrets engine and cert-manager can issue and renew certificates, but whether certificates belong in your design is a decision to confirm. Keep configuration files, account lists and audit records as evidence. See the authentik provider documentation for the options available.

How DeployOpen prepares 3.5.4 evidence

DeployOpen's work on IA.L2-3.5.4 starts with a written, fixed scope that names which systems, identity providers and privileged account paths fall under the replay-resistance requirement. Before any build, we agree in writing which network access paths for privileged and non-privileged accounts will be covered, which applications delegate sign-in, and which systems are out of scope. The client owns the control and the decision to accept any residual risk. DeployOpen then plans and implements the open-source identity services inside the client's own cloud accounts, data center or air-gapped network, typically a directory and Kerberos layer such as FreeIPA for Linux and UNIX access and an identity provider such as authentik for applications. Deliverables and timelines are set in the scope document, so the client knows what is built before work begins.

Implementation focuses on the configuration an assessor will test. For Kerberos-based access, that means confirming that network logons use the ticket-based protocol with its built-in replay resistance, and that legacy protocols which send reusable login material are disabled or restricted. For applications that sign users in through authentik, it means documenting each provider, the protocol it uses, and where a password or bearer token could still be captured and replayed. Certificates for services can be issued dynamically through OpenBao's PKI secrets engine or renewed by cert-manager in Kubernetes or OpenShift, so the client can show how TLS credentials are issued and rotated. DeployOpen also hardens the hosts, documents the settings and collects configuration exports, privileged account lists and authentication logs that SP 800-171A lists as potential evidence.

DeployOpen prepares evidence but does not assess it. We do not issue assessment results, attestations or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and self-assessments are the organization's own responsibility. Before an assessor arrives, confirm with your assessor body or sponsor which evidence format they accept and whether the final versions of configuration records, not drafts, are required, because a requirement is met only when its objective is satisfied with evidence in final form. Ask any implementation partner to state in writing what it delivers, what remains the client's job, and how the client's staff will be trained to operate and explain the setup during the assessment.

IA.L2-3.5.4 Replay-resistant authentication