IA.L2-3.5.10 Cryptographically-protected passwords: evidence

What IA.L2-3.5.10 requires before a CMMC Level 2 assessment

If your organization is pursuing Conditional or Final Level 2 status, IA.L2-3.5.10 must score MET. It asks that passwords be stored and transmitted only in cryptographically protected form, which in practice means salted one-way hashes at rest and encrypted channels in transit. Under the CMMC Scoring Methodology in 32 CFR 170.24, this is a 5-point requirement, so if it is scored NOT MET, 5 points come off the maximum of 110. Because it carries more than 1 point, it cannot be carried on a plan of action and milestones (POA&M) under 32 CFR 170.21(a)(2). An assessor who finds a gap here cannot defer it to a later date while still reaching a Level 2 status.

NIST SP 800-171A, the assessment guide that CMMC Level 2 assessments use, breaks this requirement into two assessment objectives: determining whether passwords are cryptographically protected in storage, and whether they are cryptographically protected in transit. The assessor will look at the password policy, authenticator management procedures and password configurations, and will test the mechanisms that handle passwords. Hashing alone is not enough if the hashing scheme is weak or the complexity rules under IA.L2-3.5.7 let users pick short, guessable passwords, because a stolen hash database can then be cracked offline. Treat IA.L2-3.5.10 and IA.L2-3.5.7 as one design question, not two checklists.

The usual difficulty is not the hashing algorithm itself but finding every place a password is stored or sent. Legacy line-of-business applications, service accounts used by scripts, network devices, backup consoles, and integration middleware often hold or transmit credentials outside the main directory. Build an inventory of password paths before the assessment, confirm with each system owner how credentials are stored and whether login traffic is encrypted, and record the results as final, signed evidence. Confirm the exact configuration details with your platform vendors and your assessor, since the evidence an assessor accepts depends on your environment.

Which systems and password paths fall inside IA.L2-3.5.10 scope

IA.L2-3.5.10 applies to every place a password is stored or sent within the CUI boundary, not only the login page. The cards below cover the components assessors usually examine and the scoping decisions that determine how much work each one adds.

Directory and identity stores

Directories and identity providers hold the password hashes for most user accounts, so they are the first place an assessor looks for one-way protection at rest. Confirm which directory is the authoritative store, how hashes are kept, and whether any replica or sync target holds a copy. Also confirm that logon traffic to the directory is encrypted in transit, since a password sent in clear text fails the requirement even when storage is correct.

Applications with local credentials

Line-of-business applications sometimes keep their own user table, outside the central directory. Each one needs its own review: check whether it stores passwords as salted one-way hashes, whether the framework or library default is still in use, and whether login forms and API calls use encrypted channels. Applications inherited from older projects are a common source of gaps, because their password code predates current practice.

Databases and service accounts

Database user tables, connection strings and service account credentials all count as password paths. Confirm that application passwords stored in tables are hashed, not reversibly encrypted, and that database connections require encrypted transport. Credentials embedded in configuration files or scripts are harder to see, so include a search of those files in the inventory.

Network devices and appliances

Routers, firewalls, switches, storage arrays and management consoles often accept local administrator passwords. Each device's stored credential format and its management protocol both need checking, because some older appliances use unencrypted management sessions. Document the device model and firmware for each one, since the assessor will ask how the password configuration was verified on that specific platform.

CI/CD pipelines and secrets tooling

Pipeline variables, build runners and secrets managers can all hold passwords in plain form if they are not handled deliberately. A secrets manager such as OpenBao stores secrets encrypted and can issue short-lived dynamic credentials, which reduces the number of long-lived passwords in scope. Pipeline secret detection can flag credentials committed to repositories, and it writes its results to a report artifact that serves as evidence of the check.

Cloud and third-party services handling CUI

A provider that stores or processes CUI is part of the assessed environment, and its login system may be in scope if your users authenticate through it. Decide whether the provider is inside your CUI boundary or outside it, and obtain its documentation on password storage and transit encryption. Where the provider's controls cannot be inspected directly, record the responsibility split and the evidence the provider supplies, and confirm the arrangement with your assessor before the assessment.

How assessors split the password protection test

An assessor scores IA.L2-3.5.10 as two separate tests, not one. NIST SP 800-171A, the assessment procedure that CMMC Level 2 assessments use, breaks the requirement into two objectives: passwords must be cryptographically protected in storage, and they must be cryptographically protected in transit. The organization must satisfy both. A system that hashes passwords in its user database but sends them to a login service over a clear-text channel fails the requirement, and so does a system with a strong transport layer that keeps recoverable passwords in a configuration file.

The potential assessment objects named in the assessment guidance are the password policy, the authenticator management procedures, and the password configurations together with their supporting documentation. Assessors do not stop at reading the policy. They test the password-based authenticator mechanisms: they ask which hashing or one-way function the directory or application uses, check the configuration that sets it, look at how credentials cross the network, and confirm that the documented procedure matches what the running system does. Ask your engineering team to produce the hashing settings, a sample of stored credential formats, and a capture or configuration export showing the login path. Confirm these exports with your assessor before you rely on them.

Under the CMMC scoring method, IA.L2-3.5.10 is worth 5 points, and it cannot be placed on a plan of action and milestones. A requirement is MET only when every applicable objective is satisfied with evidence in final form, so a draft policy or an unfinished configuration baseline does not count. Before the assessment, confirm which systems hold or transmit passwords, including legacy applications, service accounts and integrations, and assign a named owner to each objective. Ask your Registered Practitioner or consultant to show you where any gap would surface, but keep the determination of MET with the independent assessor.

How an assessor tests IA.L2-3.5.10 and what they ask to see

This table compares what an assessor tests for each part of IA.L2-3.5.10, the evidence they request and the findings that most often stop a requirement from being MET. Read it as a checklist for your own evidence folder: each row names an objective or artifact the assessor will open, so gaps show up before the assessment does.

Test area	Evidence requested	Common findings
Storage objective (SP 800-171A, first objective)	Directory and application configuration showing that stored passwords are hashed with a one-way function, plus the hashing algorithm, salt handling and work factor settings in use	Plaintext or reversibly encrypted passwords, unsalted hashes, or fast general-purpose hashes used where a password-specific key derivation function is expected
Transit objective (SP 800-171A, second objective)	Network diagrams and configuration for every login path, including TLS settings for web, VPN, remote desktop, API and directory bind traffic	Login forms or basic authentication served over unencrypted HTTP, LDAP simple binds without TLS, or legacy protocols still accepting cleartext credentials
Password policy and procedures	The approved password policy, authenticator management procedure and any standard that names the hashing and transport requirements, with dates and approval records	Policy silent on storage or transmission, procedures that contradict the configured system, or documents that were drafted but never approved
Configuration samples from directories and applications	Exported settings or screenshots from the identity provider, directory, databases and key applications that store credentials, captured with timestamps and system names	Samples taken from a test instance rather than production, settings that differ between sites, or applications with no sample at all
Testing of login traffic	Packet captures, proxy logs or scanner output showing that credentials cross the network only inside encrypted sessions, and a record of who ran the test and when	Credentials visible in captures, redirects that drop from HTTPS to HTTP, or internal tools that send passwords in URLs or logs
Legacy and exception handling	A documented exception register with the system, the business reason, compensating controls, an owner and a retirement date, approved by the organization	Undocumented exceptions for older systems, exceptions with no end date, or compensating controls that do not address offline cracking or interception
Interview and walkthrough	Demonstration by administrators of how a password is set, changed and stored, and how TLS is enforced on login endpoints	Staff describe a process the configuration does not reflect, or cannot explain where hashing settings are maintained
Link to IA.L2-3.5.7 password complexity	Evidence that complexity settings are enforced, since strong hashing does not prevent cracking of weak passwords	Hashes obtained through a breach that are crackable because the complexity policy is weak or unenforced

Steps to make every password path cryptographically protected

This sequence finds every place a password is accepted, stored or sent, confirms each one uses a one-way hash at rest and encrypted transport in motion, and leaves behind evidence an assessor can test against the two IA.L2-3.5.10 objectives. The organization owns the result, while an implementation partner can prepare the configurations and records.

Inventory every password entry and storage point
List every system, application, directory, appliance, script and integration that accepts a password, stores a password-derived value, or passes a password to another service. Include administrative consoles, database accounts, service accounts, VPN and remote access gateways, and any custom code. Record the owner and the system security plan boundary for each item. The output is a password path register that the team signs off on, and it is complete when a sample login from each listed system can be traced to a row in the register.
Classify storage and transit for each path
For each register entry, record how the password is stored (hashed with a one-way function, reversibly encrypted, held in plain text, or not stored at all) and how it travels (over a protected channel, over a channel that is not protected, or in a URL or log). Flag any path that stores recoverable passwords or sends them without transport encryption. The output is a classification table with a pass or fail column for storage and transit, reviewed by someone other than the system owner.
Configure one-way hashing for stored passwords
Where a password is stored locally, configure the platform or application to use a salted, one-way password hashing function that the product documents for this purpose, and confirm the work factor against the vendor guidance. Where the product cannot do this, schedule a replacement or a compensating design and record the decision. Systems that delegate authentication to a central directory should be checked for the same property at that directory. The output is a configuration record per system, and the check is that a test account's stored value is not reversible or readable by administrators.
Enforce encrypted channels for password transit
Configure every login endpoint, API, management interface and inter-service call that carries a password to use current, encrypted transport. Disable plain-text listeners and legacy protocol versions on those endpoints, and review certificate management for each. Confirm the configuration with a scan from the network path that reaches the service. The output is a transport configuration record and scan results, and the step closes when no password-bearing endpoint responds on an unencrypted port.
Remove embedded and plain-text credentials
Search source repositories, pipeline definitions, container images, configuration files, scripts and logs for hard-coded passwords and secrets. Move the remaining credentials into a managed secrets store, rotate any exposed value, and replace static service passwords with short-lived credentials where the platform supports it. An open-source pipeline secret detection job can scan committed code as part of this work, and its report becomes evidence. The output is a clean scan report, a rotation log and a secrets store inventory.
Verify with test logins and configuration review
Run controlled test logins against each register entry and capture the network traffic to show the password is sent over an encrypted channel. Inspect the stored credential representation for each account type, and review configuration exports against the documented settings. Independent review by a person outside the implementation team strengthens the evidence. The output is a test record for each register entry, and any failure reopens step three or four before the sequence closes.
Write the procedure and retain the evidence
Document the password storage and transport standard, the approved configurations, the register and the procedure for adding a new password path. Assign an owner, set a review cycle the organization defines, and keep the signed register, configuration records, scan reports and test records in final form, not drafts. Ask the independent assessor which artifacts they expect to see, since the assessment objectives are tested against the policy, the authenticator management procedures and the configuration documentation. The output is an approved procedure and an evidence folder that maps each path to its proof.

Evidence that passes an IA.L2-3.5.10 assessment

An assessor testing IA.L2-3.5.10 looks for proof that passwords are protected by a one-way function in storage and by encryption in transit, and that the organization controls both. The cards below cover the artifacts that together show the policy, the procedure, the configuration and the running systems agree. Every artifact must be in final form, current and tied to the systems in scope.

Password policy document

The approved policy states that passwords are stored only as salted one-way hashes and transmitted only over encrypted channels, and it names the systems it covers. Assessors check that the document is signed, dated, under version control and matches what the configurations actually do. Confirm the policy also addresses the complexity and reuse rules under IA.L2-3.5.7 and IA.L2-3.5.8, since weak complexity can still allow offline cracking of hashes. A draft policy does not satisfy the assessment.

Authenticator management procedure

This procedure describes how passwords are created, stored, rotated, reset and retired, and who performs each step. It should name the hashing approach for each identity store and describe how credentials are handled when accounts are provisioned or recovered. Assessors compare the procedure with the authenticator tests they perform, so every step described must be something a person or system actually does. Keep the revision history so reviewers can see when the process last changed.

Configuration exports for hashing and TLS

Export the actual settings from directory services, databases, applications and load balancers that show the password hashing algorithm and the minimum TLS version and cipher configuration used for authentication traffic. Capture the configuration files or screenshots with the date and host name visible. Check that the exports cover every authentication path, including administrative consoles and service accounts. Mismatches between the exported settings and the written policy are a common reason an objective is not met.

Password inventory by system

A current inventory lists each system or application that stores or accepts a password, the storage method, the transit method and the owner. Illustrative example: a line for a directory service might record salted hashing at rest and TLS for LDAP binds. Assessors use the inventory to choose which systems to test, so omissions are costly. Review the inventory whenever a system is added, retired or reconfigured, and record who approved each change.

Secret detection and scan reports

Scanning output shows whether credentials are stored in code, configuration files or pipelines in plain text. GitLab Community Edition pipeline secret detection writes findings to a gl-secret-detection-report.json job artifact, which can be retained as evidence. Keep the reports from recent pipeline runs and record how each finding was triaged and fixed. A scanner only proves something if its scope and rule set are documented, so confirm what it covers before relying on it.

Change records for authentication settings

Change tickets show when hashing, TLS or password settings were altered, who approved the change and whether it was tested before release. Assessors use them to confirm that the configuration exports reflect controlled change and not undocumented drift. Link each change to the configuration baseline it affected. Records should be kept for the period the organization's own retention rules require, and gaps in the sequence should be explained in writing.

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

Most of the cost of IA.L2-3.5.10 is internal engineering time, not licences. The requirement is scored as a 5-point item, so it must be fully MET, and the work starts with an inventory of every place a password is stored or sent. That means directory services, local accounts on servers and network devices, application login databases, service accounts with embedded credentials, scripts, and any integration that forwards a password to another system. Engineers and application owners spend time finding these, confirming how each one hashes or transmits credentials, and then migrating the ones that do not meet the one-way storage or encrypted transit expectation. The number of legacy applications is the single biggest driver: each one that stores credentials in a weak or reversible form, or that sends them in clear text, is a separate remediation project with its own testing and change window.

Some costs are one-time and some recur. The one-time work covers the inventory, migrations, configuration changes, and the first evidence pack that shows the password policy, authenticator management procedures and password configurations that the assessment objectives examine. The recurring work covers keeping that evidence current, reviewing new applications before they go live, re-checking configurations after upgrades, and running periodic tests of the authenticator mechanisms. Tooling spend varies widely. Open-source secret management and scanning tools can reduce licence cost, but they still require configuration, operation and staff time. Confirm with your vendors or integrators which items carry licence fees, support contracts or hosting costs, and which are internal labor.

Consolidating onto a central identity store is the most effective way to keep effort down, because it moves hashing and transport protection into a small number of systems that can be tested once and evidenced in one place. Ask any provider for a quote that itemizes the inventory, each migration, the testing and rollback plan, the evidence deliverables, and any retainer for ongoing review. Ask who performs the password configuration tests and whether the scope includes the assessor-facing documentation. Independent assessors and certification bodies charge for their own assessment work, and an implementation partner cannot issue a result, so the quote should show only the preparation effort and leave assessment fees as a separate line.

Open-source tools that support password and secret evidence

None of the tools below hashes passwords for you, and none of them makes a system meet IA.L2-3.5.10 on its own. Each one supports a related part of the evidence, such as keeping secrets out of plain text, issuing short-lived credentials, and showing that stored data is encrypted. Confirm each capability against your own configuration before you cite it in an assessment.

OpenBao for secret storage

OpenBao, an MPL-2.0 licensed project, keeps secrets encrypted in one central store rather than in scripts, configuration files or spreadsheets. For IA.L2-3.5.10, that gives assessors a single place to examine how service credentials are protected at rest. Confirm how it is deployed, how its encryption keys are unsealed and held, and whether your application credentials are actually retrieved from it rather than copied elsewhere.

Dynamic short-lived credentials

OpenBao can generate credentials for systems such as databases on demand, so a long-lived static password does not need to sit in an application. This reduces how many stored passwords exist to be protected. Ask your team which accounts still rely on static passwords and whether each one has a documented reason to remain, because those are the passwords an assessor will ask you to show protected.

Leases and revocation

Credentials issued by OpenBao can carry leases that revoke them automatically on expiry. Single secrets or whole trees of credentials can also be revoked manually, which matters when staff change roles or a secret may have leaked. Test the revocation path in a non-production environment and record the results, since a revocation that has never been exercised is weak evidence for an assessor.

GitLab pipeline secret detection

GitLab Community Edition (MIT) includes pipeline secret detection, which scans files committed and pushed to a repository inside a CI/CD job. Detected secrets are written to a gl-secret-detection-report.json job artifact. Plaintext passwords or keys found in code are exactly what IA.L2-3.5.10 is meant to prevent, so keep the artifacts with your pipeline records. Confirm which scanner rules run in your pipeline, and that findings are triaged and not simply left in the report.

Nextcloud server-side encryption

Nextcloud (AGPL-3.0-only) offers server-side encryption that protects file contents at rest on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, so credentials or sensitive identifiers should not be stored as file names. Confirm the encryption module is enabled, decide who holds recovery keys, and document the gap for file metadata in your system security plan.

restic repository encryption

restic (BSD-2-Clause) encrypts all data it stores in a repository with AES-256 in counter mode and authenticates it with a Poly1305-AES message authentication code. This supports the encryption-at-rest part of protecting backups that may contain credentials or configuration secrets. Confirm where the repository password is stored, because a strong repository cipher does not protect a repository password kept in plain text beside the backup.

Who owns IA.L2-3.5.10 work and who the assessor is

Your organization owns IA.L2-3.5.10. That means you decide how passwords are stored and transmitted, approve the final password policy, and remain accountable for the system security plan entries that describe this control. Assessors will look for evidence that the policy is in force and that the systems behave as the policy states, so the people who run those systems must be able to explain them.

Policy ownership: Approve the password policy and the authenticator management procedure that govern how credentials are created, stored and sent.
Decision on mechanisms: Choose the approved one-way function and transport protection for each system, and record the reasons.
Accountability for the SSP: Confirm that the security plan describes the real configuration of each in-scope system.
Operational proof: Keep configuration exports, change records and access reviews in final form, not drafts.
Interview readiness: Make sure administrators can explain how passwords are protected in each system.

Before assessment, check that every in-scope system has a named owner who can produce current evidence on request.

Common gaps that cause IA.L2-3.5.10 to score NOT MET

IA.L2-3.5.10 is a 5-point requirement that cannot go on a POA&M, so a single gap in password protection can keep an organization from reaching Conditional or Final Level 2 status. The gaps below come up repeatedly because they sit in places teams do not routinely review: legacy applications, scripts, login paths and policy documents. Each card names what to check and the action that closes it.

Legacy and vendor applications store passwords reversibly

Older line-of-business applications and some vendor products keep passwords in a form that can be decrypted with a key stored nearby, or in plain text inside a configuration table. The requirement calls for one-way protection in storage, so reversible storage is a direct miss even when the database is access-controlled. Check the authentication module, the user table schema and any export or backup routine. Close the gap by requiring the vendor to confirm the hashing method in writing, or by replacing or isolating the application before the assessment.

Fast or unsalted hashes

A password hash is only a protection if it is slow to compute and unique per account. Hashes produced by general-purpose fast digests, or by any algorithm applied without a per-user salt, let an attacker who obtains the database test guesses at high speed and recognize identical passwords across accounts. The CMMC Assessment Guide treats the one-way function as the core of this requirement, and weak complexity under IA.L2-3.5.7 makes offline cracking easier. Ask each system owner to name the algorithm, work factor and salt handling, and retest any hash that does not meet a password-hashing standard the organization can cite.

Service account credentials in scripts

Scripts, configuration files and CI jobs often embed service account passwords in clear text, and those files are copied into repositories, tickets and shared drives. The password is then transmitted and stored outside any protected mechanism, which fails both the storage and transit objectives. Run secret detection across repositories and build logs, then rotate every exposed credential. Move remaining secrets into a managed secret store that issues credentials at runtime, and record the change in the authenticator management procedure.

Login pages served without TLS

A login form that is reachable over plain HTTP, or a redirect that sends credentials before the encrypted session starts, transmits passwords without cryptographic protection. This is the transit half of the requirement, and assessors test it by attempting the login path from the network the users actually use. Check internal portals, VPN landing pages, legacy admin consoles and any system that accepts a password through a non-TLS API. Confirm that every authentication endpoint enforces encryption and that the server configuration rejects unencrypted connections.

Policy documents that do not match configuration

The password policy may state that passwords are hashed and transmitted over encrypted channels while the systems themselves are configured otherwise. Assessors test the stated policy, the authenticator management procedures and the actual password configurations, and a mismatch between them is treated as a failure of the requirement. Compare each written statement with a configuration export or a test result from the system. Where they differ, correct the system or the document, then keep the corrected version as the final evidence.

Questions buyers ask about IA.L2-3.5.10

What is IA.L2-3.5.10 worth, and why can it not go on a POA&M?

IA.L2-3.5.10 is a 5-point requirement under the CMMC Scoring Methodology in 32 CFR 170.24. If it is NOT MET, 5 points are subtracted from the maximum score of 110. The plan of action and milestones rules in 32 CFR 170.21 only allow requirements worth 1 point on a POA&M, so this one must be fully MET before an organization can reach Conditional or Final Level 2 status. The practical consequence is that a gap in password storage or transmission cannot be carried as a dated open item while the organization bids on work. Confirm the point values and POA&M eligibility against the current eCFR text before you rely on them, because the rule is the source for both.

Is a self-assessment enough while CMMC Phase II is suspended?

For most Level 2 contracts, the current position is that self-assessments are the form of assessment in use, but the status changes over time. The Department of War suspended Phase II on 13 July 2026, and it said Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Your contracting officer and the clauses in your contracts decide which assessment you need, so check those documents rather than relying on a general reading. Whatever form applies, the assessor or your own review will test the same objectives in NIST SP 800-171A, so the work to pass IA.L2-3.5.10 is the same. Confirm the current status on the DoW CIO About CMMC page before each bid.

How long does remediating IA.L2-3.5.10 take?

No duration is supplied for this requirement, so treat any number you hear as unverified. The time depends on scope: how many identity stores, applications, appliances and scripts hold passwords, whether they already use salted one-way hashes, whether any service still sends credentials over clear channels, and whether teams must change code or only configuration. Start with a short scoping exercise that lists every place a password is created, stored, checked or sent, including service accounts and integration credentials. Ask any partner for a written scope and timeline that lists those systems, because the fixed scope sets the schedule. Ask your own engineers to inventory first so the estimate rests on your environment.

Can our team fix IA.L2-3.5.10 in-house?

Often yes, if your engineers know how your identity provider, directories, applications and network devices store and transmit credentials. The work usually falls into three parts: confirming storage uses a one-way function with salt, confirming every login path uses an encrypted channel, and producing evidence such as the password policy, authenticator management procedures and configuration exports that assessors list as assessment objects in NIST SP 800-171A. The weak point is often a legacy application or an integration that nobody owns. Read the CMMC Assessment Guide Level 2 for the one-way function expectation, and note that strong storage does not help if IA.L2-3.5.7 complexity rules allow offline cracking of weak passwords. An internal team should test each system against those objectives before concluding the requirement is met.

What does an implementation partner need from our organization?

A partner needs access and decisions, not just documents. Expect to provide a list of identity systems, applications and devices in the CUI boundary, read-only administrative access to their configuration, the current password policy and authenticator procedures, and named owners who can approve changes. You also need to decide who signs off on exceptions and who owns evidence after the engagement ends. Because DeployOpen implements and documents controls inside your own infrastructure, your cloud accounts, data centers or networks must be available for testing and change windows must be agreed. Ask for the list of inputs in the written scope so the schedule does not depend on information requests made during the work.

Can an implementation partner also act as our assessor?

No. The organization owns its controls, an implementation partner prepares systems and evidence, and only an independent assessor issues the result. For Level 2 certification, that is a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. A partner that configures your password storage cannot also score that work for you, because the assessor must be independent of the organization being assessed and of anyone who helped build the environment. Self-assessments are performed by your organization, so the person scoring the requirement should not be the engineer who wrote the fix. Ask any firm to describe the boundary between its implementation work and the independent assessment in writing.

Which open-source tools help produce evidence for password protection?

Open-source tools do not make passwords compliant by themselves, but they can keep credentials out of places where they should not be and produce records assessors can read. OpenBao stores secrets encrypted in one place and issues short-lived dynamic credentials with leases that revoke automatically, which reduces the number of long-lived passwords in scripts and configuration. GitLab Community Edition pipeline secret detection writes findings to a gl-secret-detection-report.json artifact, which helps show that credentials are not committed to repositories. Confirm that each product covers your specific systems, and keep the configuration exports and policy documents that show the one-way function and encrypted channel settings in use.

How DeployOpen prepares IA.L2-3.5.10 evidence

DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For IA.L2-3.5.10, that work can include configuring the directory or identity service, the secrets platform and the application login paths so that passwords are hashed with a salted one-way function at rest and carried only over encrypted channels in transit, then collecting the configuration exports, test records and procedure documents an assessor will examine. DeployOpen does not own the control. Your organization must decide the password policy, approve the authenticator procedures and accept the residual risk, and an independent assessor must judge whether the objectives are met.

Before any work starts, the scope, deliverables and timelines are agreed in writing. For this requirement, a useful scope statement names every system that stores or accepts a password, including the identity provider, databases, administrative consoles, service accounts and any self-hosted tools that handle credentials. It also states which evidence will be delivered in final form, such as the password policy document, the storage hashing settings, TLS configuration output for each login endpoint and a record of how plaintext credentials were confirmed absent from logs and backups. DeployOpen does not publish a price list. A quote follows from that written scope, so the more precisely your systems are listed, the more precisely the quote can reflect the work.

DeployOpen does not issue audit reports, attestations or certifications. Those come only from the independent assessor, which for CMMC Level 2 certification is a C3PAO authorized or accredited by The Cyber AB. Confirm with your assessor which evidence formats they accept and whether they will test your configurations live, because the assessment objectives for 3.5.10 cover both storage and transit. Also confirm the current assessment path for your contracts, since the Department of War suspended Phase II in July 2026 and the CMMC requirements in force for your contract should be checked against the CMMC Program rule and your contracting officer's direction.