CMMC Level 2 key management with self-hosted secrets

How self-hosted secrets management supports CMMC key management

A defense contractor or subcontractor that handles controlled unclassified information (CUI) needs to show that its cryptographic keys and stored passwords are managed, not scattered across scripts, configuration files and hypervisor consoles. A self-hosted OpenBao deployment, run inside the organization's own environment, can serve the key and password requirements SC.L2-3.13.10, SC.L2-3.13.11 and IA.L2-3.5.10, but the scope boundary, the policies and the evidence remain the organization's responsibility and must be defined by it. The CMMC Level 2 requirements are identical to NIST SP 800-171 Revision 2 under 32 CFR 170.14(c)(3), and 32 CFR 170.4 counts 110 of them. Assessors judge each requirement against the assessment objectives in NIST SP 800-171A (June 2018), so a control counts only when its objectives are satisfied with evidence in final form.

The schedule has moved, so confirm the current status before planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. As of 17 October 2026, the DoW CIO's About CMMC page says implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. Ask your contracting officer which requirement applies to your contracts and whether a certification assessment is expected.

Scoring makes the key work worth prioritizing. Under 32 CFR 170.24, SC.L2-3.13.10 is worth 1 point, while SC.L2-3.13.11 costs 5 points if encryption is not employed and 3 points if encryption is used without FIPS-validated cryptography. Confirm with your assessor and your module vendor that the OpenBao build and the cryptographic modules underneath it hold FIPS validation for your use, because OpenBao's open source status does not establish that by itself. For IA.L2-3.5.10, assessors check that passwords are protected in storage and in transit, so decide which application and service accounts will move into the manager, and document the storage backend and transport settings that prove it.

Mapping SC.L2-3.13.10, SC.L2-3.13.11 and IA.L2-3.5.10 to secrets manager configuration

This table maps each of the three CMMC Level 2 requirements to what it asks for, the NIST SP 800-171A objectives an assessor checks, the point value under 32 CFR 170.24, and the OpenBao configuration areas that address it. Read each row as a question to answer with evidence from your own deployment, since the configuration named is a starting point rather than proof of compliance.

Requirement	What it asks for and assessment objectives	Point value (32 CFR 170.24)	OpenBao configuration that addresses it
SC.L2-3.13.10 (cryptographic key establishment and management)	Establish and manage cryptographic keys wherever cryptography is employed. Two objectives: keys are established, and keys are managed.	1 point. May go on a POA&M for Conditional Level 2 if the score is at least 88 of 110, with closeout due within 180 days.	Transit and encryption-as-a-service keys with defined rotation, versioning and retirement; seal key custody and recovery key procedures documented as the key establishment record; audit logs for key operations.
SC.L2-3.13.11 (FIPS-validated cryptography for CUI)	Employ FIPS-validated cryptography to protect CUI confidentiality. One objective: FIPS-validated cryptography is employed.	5 points if encryption is not employed, 3 points if encryption is used but not FIPS-validated. Only requirement above 1 point eligible for a POA&M, and only in the 3-point case.	Confirm the FIPS-validated build or module in use and the boundary it covers; apply it to storage encryption, seal wrapping and encryption-as-a-service for CUI-bearing data. Confirm validation status with the vendor.
IA.L2-3.5.10 (cryptographically protected passwords)	Store and transmit only cryptographically protected passwords. Two objectives: passwords are protected in storage, and passwords are protected in transit.	Scored as a 1-point requirement under 32 CFR 170.24 in the Level 2 model.	Storage: confirm that secrets are encrypted before they reach the storage backend (PostgreSQL or integrated Raft). Transit: TLS on all listeners and client connections. Auth: userpass for developer machines and AppRole for servers, with password policy and login MFA where supported.
Storage encryption (supports 3.13.10 and 3.13.11)	Protects secrets and keys at rest. Assessors expect evidence that stored material is unreadable without the active keys.	Counts toward the cryptography requirements above rather than as a separate point line.	OpenBao encrypts key/value data before writing it to storage. Confirm backend choice (integrated storage, PostgreSQL) and whether database-level encryption is also in scope.
Seal and unseal design (supports 3.13.10)	Shows who can recover the master key material and how the process is controlled and logged.	Counts toward 3.13.10 evidence.	Document the unseal method, key share custody, and recovery procedure. Ask the partner how unseal material is split between custodians and how each unseal event is recorded.
TLS in transit (supports 3.5.10 and 3.13.11)	Protects secret and key traffic between clients, nodes and the cluster, including cluster-internal replication.	Counts toward 3.5.10 transit evidence and 3.13.11 for CUI in transit.	Enable TLS on the API listener and cluster ports, restrict cipher suites to those validated for your environment, and record certificate ownership and renewal dates in the system security plan.
Auth methods for people and workloads (supports 3.5.10)	Confirms that identities authenticating to the secrets manager are verified and that credentials are not stored in plain form.	Counts toward 3.5.10 evidence and related identification and authentication practices.	Map each auth method (AppRole, JWT/OIDC, Kubernetes, LDAP, TLS certificates, userpass) to a documented user population. Confirm which methods your own directory and workloads can use.
Audit logging of key and secret access	Lets an assessor trace who used or changed a key or password. Evidence is expected in final, reviewable form.	Supports all three requirements when assessors test objectives with evidence.	Enable the audit device, forward logs to your SIEM, and retain records per your retention policy. Confirm log integrity controls with the partner.

Which open-source platforms fit CUI key management

A CUI key manager has to create, store, rotate and audit keys and passwords in your own environment, and the platform choice decides which controls you inherit and which you build. The cards below cover the primary candidate, an alternative to confirm, the Kubernetes encryption control that often gets overlooked, and the license reason HashiCorp Vault is excluded from an open-source-only design.

OpenBao as the primary choice

OpenBao is the primary candidate because it is licensed under MPL-2.0 and hosted under the OpenSSF, so the code and governance sit outside a single vendor's relicensing decisions. It provides encryption as a service, dynamic secrets, leasing with automatic revocation and bulk revocation, which map to key lifecycle and credential control. Storage runs on integrated Raft or PostgreSQL. Check that the build and configuration you deploy meet the FIPS-validated cryptography requirement, and confirm the storage backend and HA design with your assessor's evidence needs.

Infisical as an alternative

Infisical is licensed under MIT, but content in its ee directories carries a separate enterprise license, so the license boundary has to be mapped feature by feature. Before selecting it, confirm which key management, certificate and access features you need are in the MIT-licensed core, whether your FIPS-validated cryptography requirement can be met in the build you intend to run, and how its audit logs are exported to your SIEM. Treat it as a viable comparison, not a drop-in substitute, until those checks pass.

Kubernetes encryption at rest

If your CUI workloads run on Kubernetes, Secrets are stored unencrypted in etcd by default. Configuring encryption at rest for the API server, restricting list and watch access with least-privilege RBAC, or using an external store through the Secrets Store CSI Driver are supporting controls, not a key manager. Confirm that the encryption provider in your cluster uses FIPS-validated cryptography, and document where the encryption key itself is held and rotated so it does not sit beside the data it protects.

HashiCorp Vault excluded by license

HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. A design that must be open-source only therefore cannot rely on current Vault releases, even though earlier versions carry different terms. Confirm the license of any Vault version already in your environment with counsel before planning a migration, since the migration path to OpenBao is a separate decision from the one about the new design.

How the key hierarchy and access model fit a CUI enclave

The CUI enclave boundary should be drawn before any OpenBao node is deployed. Every system that stores, processes or transmits CUI, plus the OpenBao cluster that holds the keys protecting it, belongs inside that boundary, and the cluster's storage backend, load balancers, backups and administrative workstations do too. Keys and secrets for CUI systems should not be issued by a service outside the enclave, so the seal, storage and audit paths need to terminate inside it. Confirm with your assessor how the enclave boundary is documented in the system security plan, since that document is the evidence a reviewer will read first. Also confirm which OpenBao build you intend to run and whether its cryptographic modules meet the FIPS-validated requirement of SC.L2-3.13.11. The open-source releases are not presented here as FIPS-validated, so that status must come from the build's own validation documentation and your own testing.

Access should follow identity type, and each identity type should map to one auth method and one narrowly scoped policy. Servers and services should authenticate with AppRole, which OpenBao recommends for servers, with the secret_id delivered through a controlled channel and short-lived. Workloads on Kubernetes or CI runners should use the Kubernetes or JWT/OIDC auth methods so that each pod or job receives a token bound to its service account or claims. Userpass is recommended for developer machines, so restrict it to named engineers working through a controlled workflow, enforce login MFA where it is available, and remove it from any path that a production service can reach. Each auth method should map to a policy that grants access to a single path, such as one secret/ mount or one transit key, and the mapping should be reviewed against the access model before go-live.

Seal and recovery keys define who can bring the cluster back after a restart, so custody is a design decision rather than an afterthought. Split the unseal or recovery key shares among named custodians, store each share in a separate controlled location inside the enclave, and document the quorum required to unseal. Test the recovery procedure on a non-production cluster, and record each custodian's acknowledgment as evidence. Ask your implementation partner how they will document custody, rotation of shares and the procedure for a lost share, since those answers feed directly into the access control and key management evidence an assessor will request.

Choosing a storage and HA design for a defense contractor

Integrated storage (Raft) is one of the officially supported storage backends and HA options for OpenBao. It keeps secret data in a cluster that OpenBao manages itself, so the team does not run a separate database service for the secrets store. The cost is that the team must operate the Raft cluster directly: node placement, peer membership, snapshots and upgrades all fall to the platform team.

Node count: HA uses an active node that holds a lock and standby nodes that forward or redirect requests. Confirm the node count and failure domains with your partner before procurement.
Operations ownership: The platform team owns Raft membership changes, certificate rotation between nodes and version upgrades in sequence.
Read scaling: Since OpenBao 2.5.0, Raft standbys can serve read-only operations, which helps with read-heavy workloads.
Backups: Snapshot schedules, storage location and encryption of backup media must be defined and tested.
Restore evidence: Keep dated records of restores into a separate environment, including the time to recover and the unseal steps used.

Before you commit, ask your partner to show a restore of a Raft snapshot into an isolated cluster and the runbook that the on-call team would follow.

Evidence assessors ask for on key management and CUI encryption

This table lists the evidence an assessor typically asks for when a self-hosted OpenBao deployment supports SC.L2-3.13.10, SC.L2-3.13.11 and IA.L2-3.5.10. Each row names the component that produces the evidence and what to confirm before the assessment. Assessments accept only final-form evidence under 32 CFR 170.16 and 170.17, so treat drafts and undated exports as gaps.

Evidence item	Component that produces it	What the assessor checks and where it usually fails
Key generation and rotation records	OpenBao key management and transit or PKI engines, plus the rotation runbook	Keys were established and managed when cryptography is used (SC.L2-3.13.10). Failures happen when rotation history is missing or was performed by hand without a record.
Policy exports and access logs	OpenBao policies and audit devices writing to a log store	Access to keys and secrets is limited and recorded. Assessors look for complete logs with timestamps and identities, and for proof that logs are retained and reviewed.
Auth method configuration	OpenBao auth methods such as userpass, LDAP, OIDC/JWT, AppRole and TLS certificates, plus login MFA settings	Users and workloads are authenticated before secrets are issued (IA.L2-3.5.1 and related controls). Gaps appear when local accounts or static tokens bypass the documented method.
Storage encryption and TLS configuration	OpenBao configuration file, storage backend (integrated Raft or PostgreSQL) and the TLS termination point	Data is encrypted before it reaches storage and in transit (SC.L2-3.13.11, SC.L2-3.13.8). Assessors need configuration evidence that shows the cipher and certificate settings in use.
FIPS validation documentation	Cryptographic module vendor documentation and the build or runtime configuration of OpenBao, the operating system and the TLS library	Cryptography that protects CUI is FIPS-validated (SC.L2-3.13.11). Confirm that the specific module version and mode in use appear on the validation list. A 3-point score applies when encryption is used without FIPS validation.
Backup and restore test records	Backup job for the storage backend, restore test log and unseal material custody record	Keys and secrets can be recovered after loss. Failures occur when backups have never been restored or the unseal or recovery keys cannot be located during the test.
System Security Plan entries	Client System Security Plan, maintained by the organization with DeployOpen documentation as input	The SSP describes how each requirement is implemented, who owns it and where the evidence lives. Entries that describe OpenBao but do not match the deployed configuration are a common finding.

What a secrets manager alone does not satisfy

A self-hosted secrets manager covers part of the key management picture for CMMC Level 2, but the assessment looks at the whole system boundary. The cards below cover the gaps an assessor is most likely to probe, and the decisions that sit with your organization rather than with the software.

FIPS validation is a module decision

Satisfying SC.L2-3.13.11 depends on whether the cryptographic module in use is FIPS-validated and configured in a FIPS-approved mode, not on the fact that encryption is switched on. Confirm the validated module, its certificate and the operating mode for OpenBao, the operating system, the database backend and every client library. Ask the vendor which build and configuration are validated, because a general-purpose release may not be.

Passwords protected in transit and at rest

IA.L2-3.5.10 is assessed on two objectives: passwords protected in storage and protected in transit. A vault that stores secrets well does not help if a legacy application still sends passwords over an unencrypted connection, or if a database holds user passwords in a reversible form. Inventory every system in scope that authenticates users or services, then check how each one stores and transmits its password material.

Hard-coded credentials in apps and endpoints

Moving secrets into OpenBao does not remove the copies already sitting in scripts, configuration files, build pipelines, scheduled tasks and endpoint images. Each leftover credential is a path around the vault and an evidence gap during the assessment. Plan a discovery pass across repositories, servers and workstations in the CUI boundary, then rotate what is found and replace the static copy with a retrieval call wherever the application supports it.

Policies and training for key handling

Assessors look for written procedures that say who generates, distributes, rotates, escrows and destroys keys, and for evidence that administrators follow them. A running system does not replace this paperwork. Confirm that your key lifecycle and password rules are written, approved and communicated to the staff who unseal the vault, administer policies and request secrets, and that training records exist for them.

System Security Plan and POA&M decisions

Your System Security Plan must describe how the secrets manager, its storage backend, its network path and its administrators fit the CUI boundary. Any gap you cannot close before assessment needs a plan of action and milestones, but only some requirements may be placed there. Decide early which requirements the secrets manager satisfies outright and which depend on other controls, and confirm the current POA&M rules with your assessor or contracting office.

Preparation is not assessment

DeployOpen prepares systems, controls and evidence for a CMMC assessment, but it does not issue audit reports, attestations or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body. Ask your implementation partner for a written evidence map that shows which artifacts support each objective, and confirm with your sponsor how the current CMMC phase affects whether a certification assessment is required for your contracts.

How a CMMC key management rollout runs in phases

The sequence moves from defining the CUI boundary and inventorying keys and passwords to a running OpenBao cluster, migrated secrets, and an evidence package that has been dry-run against the NIST SP 800-171A assessment objectives. Each phase closes with a written output the assessor can trace.

Define the CUI boundary and inventory keys
Your team and DeployOpen start by mapping which systems store, process or transmit CUI, then listing every cryptographic key, certificate, password and application credential those systems depend on. The output is a boundary diagram and a key and credential inventory with an owner, location and purpose for each item. Confirm with your assessor which systems fall inside scope before any design work begins, because the inventory determines what the secrets manager must cover.
Design unseal and recovery custody
Define how the OpenBao unseal material and recovery keys are split, who holds each share, where they are stored and how a quorum is reached during an emergency. DeployOpen documents this as a written custody procedure that your key custodians sign off on. The step is complete when the custody model, the named custodians and the break-glass procedure are approved and filed with the SSP evidence.
Stand up the HA cluster in your environment
DeployOpen deploys OpenBao inside your own cloud accounts, data center or enclave, using a supported high availability backend such as integrated storage (Raft) or PostgreSQL. TLS is configured for all node traffic, the FIPS-validated cryptography requirement is checked against the build you run, and access to the management plane is restricted to named administrators. The step closes with a documented architecture, a health check record, and a tested failover of the active node.
Migrate secrets and enforce access policies
Secrets, certificates and encryption keys found in the inventory are moved into OpenBao, and each application is switched to an authentication method suited to its type, such as AppRole for servers or Kubernetes auth for workloads. Where the database or platform supports it, applications move to dynamic or short-lived credentials so that static passwords are retired. The step is complete when legacy copies in configuration files and scripts are removed and each path has a least-privilege policy.
Enable audit logging and key rotation
Audit devices are enabled, logs are forwarded to the SIEM you operate, and rotation schedules are set for keys and credentials that cannot be made dynamic. DeployOpen also verifies that the cryptographic key lifecycle (establishment, use, rotation and retirement) is exercised in a test run. The closing check is a sample audit trail showing reads, writes and policy changes reaching the SIEM.
Produce evidence for each assessment objective
For each applicable objective in NIST SP 800-171A tied to SC.L2-3.13.10, SC.L2-3.13.11 and IA.L2-3.5.10, DeployOpen collects the configuration exports, policy files, custody records, test results and log samples that show the objective is met. Evidence is finalized, not kept in draft form, and mapped to the system security plan. The step ends with an evidence index that your team can hand to a C3PAO or use for a self-assessment.
Dry-run the assessment and hand over
Before handover, your team runs a mock assessment against the evidence index, walking through each objective with the named owners and checking that every requirement has evidence that is current and complete. Gaps are either fixed or documented as a plan of action where the rules allow. Ask your implementation partner for a written timeline and a dated handover list, since this sequence depends on the scope and environment you agree to.

Questions buyers ask about CMMC key management and secrets tools

Does OpenBao alone satisfy SC.L2-3.13.11 for CUI encryption?

No. SC.L2-3.13.11 requires FIPS-validated cryptography to protect the confidentiality of CUI, and a secrets manager does not make that true by itself. OpenBao manages keys and encrypts secrets before they reach storage, but the assessor will check which cryptographic modules perform that encryption, whether they are FIPS-validated, and whether they are configured in FIPS mode. Confirm the validation status of the exact build, the operating system and the libraries with the vendor and your assessor before you rely on it. The same check applies to TLS on every path that carries CUI, not only the vault itself. The 3-point and 5-point scoring rules in 32 CFR 170.24 make this gap material, so treat it as a separate work item in your plan.

What does a CMMC key management project cost, and what drives it up?

DeployOpen does not publish prices, and a quote follows from a written scope. The main cost components are the work to design and deploy the secrets platform, the integration work for each application that reads keys or credentials, the migration of secrets already stored in code, configuration files and scripts, and the evidence work that proves the controls. Recurring costs include the infrastructure for high availability, backups, monitoring and ongoing operations. Costs rise with the number of applications, the number of environments, whether HA spans sites, the amount of existing secret sprawl, and whether HSM-backed custody is required. Ask each proposal to price these items separately and to state what is one-time and what recurs.

How long does implementation take, and how does the 2026 Phase II suspension affect timing?

Duration depends on scope, the number of systems in the CUI boundary and how much of your evidence already exists, so no single figure applies. The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Because the timing of certification requirements may change after that review, plan against your contract obligations and the current DoW CIO guidance rather than a single date. Confirm which phase applies to your contracts with your contracting officer.

What must our organization provide before a partner can start?

A partner needs access to the systems that handle CUI, a current inventory of applications, service accounts, certificates and keys, and a named owner for each system. You should also provide the existing SSP and network diagrams, identity sources such as your directory, the change process for production, and the hosting environment in your own cloud accounts, data centers or isolated network. Decision-makers must agree on unseal and recovery key custody, who approves access policies and who signs off on the evidence. Expect to provide staff time from security, platform and application owners. Ask the partner to list these inputs in the written scope so gaps are visible before work begins.

Can our internal team run this project without a partner?

A capable internal team can do it, but the work spans several disciplines at once: cryptographic configuration, HA and backup design, identity integration, application changes and assessment evidence. The assessment standard is NIST SP 800-171A, and a requirement is met only when all applicable objectives are satisfied with evidence in final form, so documentation quality matters as much as configuration. Assess honestly whether you have people who can run a Raft or PostgreSQL backed cluster, test restores and write procedures an assessor will accept. A partner can cover part of the work, such as design, migration or testing, while your team keeps ownership of the policies and operations. Define that split in the written scope.

Does the move from NIST SP 800-171 Rev. 2 to Rev. 3 change our plan?

For now, Rev. 2 still governs CMMC Level 2. NIST withdrew SP 800-171 Rev. 2 on 14 May 2024 when it published Rev. 3, but the CMMC rule still incorporates Rev. 2, and the Department of War said on 13 July 2026 that it will enforce Rev. 2 in the interim. Build your key management controls against the Rev. 2 requirement IDs such as SC.L2-3.13.10 and IA.L2-3.5.10 so your evidence maps to the assessment guide. Track any future rulemaking that adopts Rev. 3, because control numbering and objectives would change. Keep your key inventory and rotation records in a form that can be remapped without rebuilding them.

How do we handle password storage in a way that meets IA.L2-3.5.10?

IA.L2-3.5.10 asks that passwords be stored and transmitted only in cryptographically protected form. A self-hosted secrets manager can hold service account and application passwords so they are not stored in scripts or configuration files, and it can encrypt them before they reach storage. Confirm that human user credentials are handled by your identity provider rather than the vault, and that every transmission path between clients, the vault and applications uses protected channels. Ask your assessor how the assessment objectives for storage and transit will be evidenced, and keep records of where each password type lives.

What to confirm with your C3PAO or sponsor before you build

Before you commit to a design, confirm which contract clauses actually apply to your work. The DFARS clause 252.204-7021 and provision 252.204-7025 determine whether a CMMC requirement is in your contract, and your contracting officer or prime sponsor can tell you which Level applies to each contract and whether a Level 2 self-assessment or a certification assessment is expected. The DoW CIO About CMMC page is the place to check current phase status, because the rollout has changed recently. Confirm the status on the day you plan your work, and ask your sponsor in writing which phase governs your contracts, since the regulation text and the official status page may not match.

Next, agree with your assessor which assessment objectives will be used to judge each secrets and key requirement. For SC.L2-3.13.10, the NIST SP 800-171A objectives split into establishing cryptographic keys and managing them. For SC.L2-3.5.10, the objectives cover cryptographically protecting passwords in storage and in transit. Ask the assessor to show you how each objective maps to a system component, a configuration setting and a log or report that proves it. Ask for the evidence format too, because a requirement is met only when the evidence is final, not a draft. Plan that evidence from the start, including the key inventory, rotation records and access logs.

Finally, confirm the FIPS validation status of the exact cryptographic module you plan to deploy, not the product name alone. SC.L2-3.13.11 turns on whether FIPS-validated cryptography protects CUI confidentiality, and the scoring difference in 32 CFR 170.24 makes this decision material. Ask your build partner for the module version, the validation certificate and the operating mode settings that must be enabled, and verify the certificate against the NIST Cryptographic Module Validation Program guidance and your own environment. Record which FIPS-validated components are in the boundary and which are outside it, and confirm that any build you choose can run in that mode before you buy licenses or write integrations.

How DeployOpen scopes, deploys and documents CUI key management

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so CUI key management runs on systems the organization controls. For CMMC Level 2 work, we start from the written assessment objectives of NIST SP 800-171A and build evidence that an assessor can check.

How we scope

Written scope names the CUI systems, enclaves and key types that the secrets manager will protect.
Scope maps each key and password flow to SC.L2-3.13.10, SC.L2-3.13.11 and IA.L2-3.5.10.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Deployment runs in the client's own cloud accounts, data centers or enclaves, with the chosen OpenBao or Infisical version.
Configuration covers auth methods for servers and users, least-privilege policies, storage backend and high availability.
Encryption settings and FIPS-validated cryptography choices are confirmed against the client's own environment and assessor expectations.

How we hand over

Handover includes key lifecycle procedures for generation, rotation, storage, backup and retirement.
Documentation records configuration, access policies and audit log settings mapped to each in-scope requirement.
Evidence is delivered in final form so the client's assessor can test each objective against it.

How we support

Ongoing support, upgrades and testing are available as a retainer after the initial handover.
Upgrades and patches are applied to the self-hosted platform and its evidence is refreshed to match.
DeployOpen prepares systems and evidence for assessment but does not issue audit reports or certifications.

Self-hosted secrets management for CMMC key management