CM-3(6): Cryptography Management

CM-3(6): Cryptography Management requires you to treat the cryptographic mechanisms that implement security controls (libraries, modules, settings, keys, certificates, protocols) as configuration-managed items: inventoried, baselined, change-controlled, tested, approved, and monitored. Operationalize it by building a “crypto configuration baseline” and running all crypto changes through your formal configuration management process. ¹

Key takeaways:

• Put crypto under the same rigor as code and infrastructure: baseline, approve, test, document, and track changes. ¹
• Scope includes mechanisms that provide controls (for example, encryption for data protection, TLS for transmission, signing for integrity), not only “the encryption team’s tools.” ¹
• Your fastest audit win is an end-to-end evidence trail: inventory → baseline → change tickets → test results → deployment record → periodic review. ²

CM-3(6) is a configuration management requirement focused narrowly on cryptography, but it tends to expose broad operational gaps: shadow TLS termination, inconsistent cipher suites, unmanaged certificate renewals, “temporary” crypto exceptions that never get retired, and library upgrades pushed without impact analysis. The control is simple to state and hard to fake because auditors can validate crypto settings directly from endpoints, load balancers, container images, mobile apps, and code repositories.

The operator’s goal is to make cryptographic mechanisms predictable and governable. That means you can answer, quickly and defensibly: What crypto do we use, where is it configured, what is approved, who can change it, how do we test changes, and how do we detect drift? CM-3(6) does not require any specific algorithm in the text provided; it requires disciplined control over whatever cryptography you rely on to meet other security controls. ¹

If you already run change management for infrastructure, you can implement CM-3(6) without creating a new bureaucracy. You extend existing CM-3 workflows to cover crypto-specific configuration items, with crypto-aware acceptance criteria and evidence. ²

Regulatory text

Requirement (excerpt): “Ensure that cryptographic mechanisms used to provide the following controls are under configuration management: {{ insert: param, cm-03.06_odp }}.” ¹

What the operator must do: Identify the cryptographic mechanisms that your system relies on to satisfy security controls, then manage those mechanisms as controlled configuration items. Practically, that means: define approved crypto configurations (baselines), control and document changes, test and validate before release, and continuously maintain an authoritative record of what is deployed. ¹

Plain-English interpretation (what auditors expect)

Auditors and assessors will look for two things:

1. Crypto is in scope of configuration management. Crypto is not treated as “special” or exempt from change control. If TLS settings change, or a cert renews, or a crypto library version bumps, you can show a traceable change record. ²

2. Crypto configurations are intentional and repeatable. You have defined what “approved crypto” means for your environment (protocol versions, cipher suites, key sizes where applicable, certificate authorities, key storage/HSM use, signing settings, FIPS mode if required by your program) and you can show what is running now against that baseline. ¹

Who it applies to (entity and operational context)

CM-3(6) commonly applies where you claim alignment to NIST SP 800-53 in environments such as:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are in scope by contract or authorization boundary. ²

Operationally, it applies wherever cryptography is configured or embedded, including:

• Network edge: TLS termination on load balancers, API gateways, WAF/CDN settings
• Application stacks: crypto libraries, JWT signing, password hashing parameters, mTLS settings
• Data platforms: database encryption settings, backup encryption, object storage encryption
• Endpoints and mobile: embedded cert pins, bundled crypto libraries
• CI/CD: build flags (for example, enabling FIPS modes), dependency pinning, container base images

If you run a third-party hosted service, CM-3(6) still applies to what you configure and what you accept. Your due diligence focus becomes “provider-managed crypto vs customer-configured crypto” and how changes are controlled across that boundary. ²

What you actually need to do (step-by-step)

1) Define your crypto “configuration items” (CIs)

Create an explicit list of crypto-related CIs that must be change-controlled. Minimum categories:

• Protocols & endpoint configs: TLS versions, cipher suites, HSTS settings, mTLS requirements
• Certificates: issuing CAs, certificate profiles, renewal automation, revocation approach
• Keys & key management: KMS/HSM configuration, key rotation settings, access policies
• Crypto libraries & modules: OpenSSL/BoringSSL, Java/JCE providers, .NET crypto, signing libraries
• Application crypto parameters: token signing algorithms, password hashing parameters, encryption modes used by app features
• FIPS-related settings if required by your environment/program

Output: a “Cryptography Configuration Item Register” owned by Security + Platform/Engineering. Tie each CI to systems, repositories, and owners. ¹

2) Establish a crypto configuration baseline

For each CI category, document the approved baseline. Keep it implementable:

• Baseline statements (“Production ingress uses TLS; only approved protocol versions and cipher suites per baseline”)
• Concrete configuration examples (preferred: config snippets, policy-as-code, template values)
• Approved exceptions process (time-bound, risk-accepted, tracked to remediation)

Output: “Crypto Baseline Standard” plus system-specific baselines (for example, “API Gateway TLS Baseline,” “KMS Key Policy Baseline”). ²

3) Map crypto mechanisms to the controls they support

CM-3(6) is explicitly about crypto used to provide controls. Build a mapping table:

Control objective supported	Crypto mechanism	Where configured	Owner	Baseline reference
Data in transit protection	TLS termination	ALB / API gateway	Platform	TLS Baseline
Integrity / authenticity	Code signing	CI pipeline	AppSec	Signing Baseline
Data at rest protection	KMS-managed encryption	Cloud storage	Cloud Sec	KMS Baseline

This mapping is high-value for audits because it shows you understood the “used to provide controls” language and did the scoping work. ¹

4) Put crypto changes through formal configuration management

Extend your CM-3 change workflow to include crypto-specific gates:

• Trigger conditions: any change to TLS/ciphers, cert issuance/CA, key policy, crypto library version, signing config
• Required fields in the change ticket: reason, affected systems, rollback plan, testing plan, owner approval
• Approvals: Platform owner + Security/AppSec; add Risk/Compliance sign-off for exceptions
• Testing: pre-prod validation (scanner output, integration tests, backward compatibility assessment)
• Deployment traceability: link change ticket → PR/commit → pipeline run → release record

Goal: if someone asks “why did TLS settings change on Tuesday,” you can show a clean chain of custody. ²

5) Detect and correct crypto drift

Configuration management fails when reality diverges from the baseline. Add detective controls:

• Scheduled endpoint scans for TLS posture (internal and external)
• Certificate inventory and expiry monitoring
• Dependency monitoring for crypto library updates, including transitive dependencies
• Cloud configuration monitoring (KMS key policies, storage encryption flags)

Define response: open a ticket, classify as defect vs emergency change, remediate, and record outcome. ²

6) Operationalize third-party crypto dependencies

Where a third party provides encryption or key management:

• Document shared responsibility: what the provider controls vs what you configure
• Require change notifications for provider-managed crypto changes when available
• Record your configuration decisions and monitoring (for example, what TLS versions you set on the service front door)

This is a common exam gap: teams assume “SaaS handles encryption” and stop there, but CM-3(6) is about your configuration management discipline around the mechanisms in your control. ²

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

Design / governance

• Cryptography Configuration Item Register (scope list with owners)
• Crypto Baseline Standard + system-level baselines
• Control-to-crypto mapping table (controls supported → mechanisms)
• Configuration management procedure that explicitly includes cryptographic mechanisms (CM-3 alignment)

Operational evidence

• Change tickets for crypto changes (with approvals, testing, rollback)
• PRs/commits and CI/CD logs linked to change tickets
• Validation results (TLS scan outputs, config snapshots, unit/integration test evidence)
• Exception register for crypto deviations (approved, time-bound, tracked)
• Monitoring evidence: certificate inventory/expiry reports, drift findings and remediation tickets

If you use Daydream to run compliance operations, implement CM-3(6) as a recurring control with a named owner, a documented procedure, and a defined evidence set (inventory export, sample change tickets, baseline doc, drift report) so audits become a packaging exercise, not a scramble. ¹

Common exam/audit questions and hangups

Expect these questions:

• “Show me your inventory of cryptographic mechanisms in scope and who owns each.”
• “What is your approved TLS/cipher baseline and where is it enforced?”
• “Pick a recent crypto library update. Show the approvals, testing, and rollout evidence.”
• “How do you detect drift from your baseline? Show findings and remediation.”
• “How do you manage certificate issuance, renewal, and revocation under change control?”

Hangups that slow assessments:

• Crypto exists in too many places (app code, edge, mobile, service mesh) and no one has end-to-end ownership.
• Emergency changes bypass change control with no retroactive documentation.
• Certificates renew automatically, but the organization has no record that the renewal happened or that it met baseline requirements.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating CM-3(6) as “key management only.”
   Fix: expand scope to include endpoint TLS configs, cert lifecycle, crypto libraries, and application crypto parameters. Use the CI Register to force completeness. ¹

2. Mistake: baselines written as policy prose with no enforceable settings.
   Fix: include concrete config examples and where they live (templates, IaC modules, gateway policies). ²

3. Mistake: no mapping to the controls crypto supports.
   Fix: build the control-to-crypto mapping table and keep it current. This is the fastest way to show you met the “used to provide controls” clause. ¹

4. Mistake: drift monitoring exists, but remediation is informal.
   Fix: require tickets for drift findings, with severity, owner, and closure evidence. ²

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list enforcement examples.

Risk-wise, failures in crypto configuration management commonly translate into:

• exposure from weak or inconsistent TLS posture across endpoints
• outages caused by unmanaged certificate expirations or incompatible protocol changes
• integrity failures where signing settings drift or keys are mishandled
• audit findings because you cannot prove change control and baseline conformance

CM-3(6) reduces these risks by making crypto changes predictable, reviewable, and testable under your standard configuration management discipline. ²

Practical execution plan (30/60/90-day format)

You asked for speed. Use this plan as a template; adjust to your engineering release cadence.

First 30 days (establish control scope and minimum evidence)

• Assign a single control owner (Security or GRC) and technical co-owners (Platform/AppSec).
• Build the Cryptography Configuration Item Register for your highest-risk systems (external-facing + sensitive data paths).
• Publish a first version of the Crypto Baseline Standard (even if narrow: TLS + certificates + KMS).
• Update your change ticket template to flag crypto-impacting changes and require Security review.
• Capture your first evidence pack: baseline doc + inventory + sample change tickets.

Days 31–60 (make baselines enforceable and auditable)

• Convert baseline requirements into enforceable templates (IaC modules, gateway policies, CI checks).
• Add drift detection: recurring TLS scans and certificate inventory monitoring.
• Create the control-to-crypto mapping table and link it to your system inventory/SSP artifacts.
• Stand up an exception register for crypto deviations with required approvals and tracked remediation.

Days 61–90 (scale coverage and harden operations)

• Expand CI Register coverage to internal services, service mesh, mobile, and critical third parties.
• Add library/dependency governance for crypto modules (pinning, update review workflow).
• Run a tabletop: simulate cert revocation or CA change; validate your change control, rollout, and rollback evidence.
• Perform an internal assessment using your evidence pack and close gaps before external audit.

Frequently Asked Questions

Does CM-3(6) require specific algorithms (AES-256, RSA-2048, TLS 1.3)?

The provided text does not mandate specific algorithms. It requires that whatever cryptographic mechanisms you use to provide controls are managed under configuration management with baselines and controlled changes. ¹

What counts as a “cryptographic mechanism” for this requirement?

Include crypto libraries/modules, protocol configurations (TLS/ciphers), certificate and CA configurations, KMS/HSM settings, and application crypto parameters like token signing and password hashing settings. If changing it could weaken confidentiality, integrity, or authenticity, treat it as in scope. ²

We use a cloud provider’s managed encryption. Are we still on the hook?

Yes for what you configure and what you accept. Document the shared responsibility boundary, keep your own configuration (for example, KMS key policies and service encryption settings) under change control, and retain provider change notices when available. ²

How do I prove compliance quickly to an auditor?

Provide four items: a crypto CI inventory, an approved baseline, a mapping of crypto mechanisms to the controls they support, and a sample set of change records with testing and approvals. That evidence set usually answers most assessor follow-ups. ¹

Are automated certificate renewals a problem for CM-3(6)?

Automation is fine, but it still needs governance. Treat renewal configuration as a managed CI, log renewal events, and monitor for drift (wrong CA, wrong key type, wrong endpoint). Keep the audit trail. ²

What’s the single most common failure mode?

Teams cannot enumerate where crypto is configured across edge, app, and CI/CD, so changes happen without consistent review or evidence. Start with the CI Register and force ownership per mechanism. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5