Choosing a Secrets Vault Under CMMC and NIST 800-171

A commercial engineering team optimizes for developer speed and cross-platform sync. A contractor handling controlled unclassified information has to optimize for a defined, assessable boundary first, where every tool touching in-scope systems needs a clear answer about where data lives, who can access it, and under what authorization.

Both frameworks require restricting and monitoring access to systems that process controlled unclassified information, including how credentials for those systems are issued, rotated, and revoked. Neither framework names a specific commercial product as compliant, which means the responsibility for proving a tool fits your boundary sits with your organization, not the vendor.

Ask directly whether the vendor's product has FedRAMP authorization at the level your contract requires, or whether it's designed to run entirely inside an authorization boundary you control, such as a government cloud region. Get the answer in writing, because federal binding operational directives already set a hard clock on remediating a known exploited vulnerability, and your own assessor will expect a leaked credential to be treated on that same clock, not a slower internal one¹.

A self-hosted Vault instance running inside a government cloud region gives you direct control over where the secrets themselves live, which is often the deciding factor for a contractor that needs to keep the entire authorization boundary under its own operational control rather than depending on a multi-tenant vendor's infrastructure and attestations.

Don't assume a tool is acceptable inside your boundary just because it's popular or well reviewed elsewhere. Confirm directly with your compliance assessor or a qualified third-party assessment organization whether your specific deployment, not just the product in general, satisfies the requirement you're trying to meet.

Checks to complete before you treat a secrets tool as acceptable inside your boundary:

1. Ask the vendor in writing whether the specific configuration you plan to deploy carries the federal authorization your contract requires, and request documentation.
2. Confirm with your compliance assessor or a qualified third-party assessment organization that your deployment, not just the product in general, meets the requirement.
3. Decide where the secrets will physically live, such as a government cloud region you control, and record that in your authorization scope.
4. Ask every subcontractor touching the same data where their credentials live and which tools hold them, since flow-down requirements reach their choices too.

A prime contractor can do everything right on its own systems and still inherit risk from a subcontractor who stores boundary-relevant credentials in a tool that was never evaluated against the same compliance requirements. Flow-down requirements exist precisely because your authorization boundary can be affected by a subcontractor's choices, not just your own.

Confirm explicitly, in writing, what secrets management approach any subcontractor touching in-scope systems is using, and don't assume their internal practices match your own compliance obligations just because they're a capable technical team. This is worth verifying before work begins, not after an assessment raises the question.

Before adopting any secrets tool for a system inside your compliance boundary, send the vendor a direct written question: does this product, in the specific configuration you'd be deploying, carry the federal authorization your contract requires, and can they provide documentation confirming it. A vague marketing page claiming the product is secure is not an answer to that question.

If the vendor can't provide a clear, documented answer, or if their answer is that the product itself isn't authorized but can be deployed inside an already-authorized environment you control, treat that as your actual answer and plan your deployment around it. Keep that written confirmation on file alongside your other boundary documentation for your next assessment.

If a subcontractor's systems touch the same data your compliance boundary is built to protect, their credential handling practices become your problem too, not just something you can assume they've handled correctly because they signed a flow-down clause.

Ask a subcontractor the same questions your own prime or the government asks you: where credentials for shared systems live, who can access them, and how rotation and revocation get logged. A subcontractor using Vault self-hosted inside their own compliance boundary is a very different risk than one keeping a shared login in a spreadsheet, even if both technically satisfy the contract's flow-down language on paper.

Document what you confirmed and when, the same way you'd document your own controls, because an assessor reviewing your boundary won't stop at your systems if a subcontractor's access reaches inside it.

If a subcontractor can't answer these questions clearly, that's information worth having before the next task order, not after an assessor asks you the same thing and you have no record to point to.