CMMC Level 3 Caching: Access Controls and Encryption for Defense Contractors

CMMC 2.0 is now enforced. Every Department of Defense contractor handling Controlled Unclassified Information must meet CMMC Level 2 at minimum -- 110 controls from NIST SP 800-171. Contractors handling the most sensitive CUI must meet CMMC Level 3, which adds 24 enhanced controls from NIST SP 800-172 on top of the 110, totaling 134 practices that must be demonstrated to a government-led assessment team. Cache infrastructure touches at least 14 of these controls directly. Most contractors do not know their cache is a compliance gap because Redis was not designed for controlled environments. It was designed for speed, in an era when nobody expected ephemeral data stores to fall within a compliance boundary.

The problem is structural. When a defense contractor builds a system that processes CUI -- employee records, contract pricing data, technical specifications, engineering drawings, logistics information -- the performance layer caches that data. The database has FIPS-validated encryption, access controls mapped to NIST roles, and audit logs that satisfy assessor requirements. The cache sitting in front of that database has none of these. It holds the same CUI, often for minutes or hours, with zero cryptographic protection, zero access control granularity, and zero audit trail. In a CMMC assessment, that cache is a finding. Not a recommendation. A finding.

This guide maps every relevant NIST SP 800-171 and SP 800-172 control to cache-specific requirements, explains why Redis and ElastiCache cannot satisfy them, and shows how to build a cache architecture that passes CMMC Level 3 assessment without bolting compliance wrappers onto infrastructure that was never designed for controlled environments.

What CMMC Means for Your Cache Layer

CMMC 2.0 defines three levels, each with increasing rigor. Understanding which level applies to your contract is the first step. Understanding that your cache must meet the same level as the rest of your system is the second step -- and the one most contractors miss.

CMMC Level 1: Federal Contract Information (FCI). 17 practices from FAR 52.204-21. Basic cyber hygiene. FCI is information provided by or generated for the government under contract that is not intended for public release. At Level 1, you need basic access controls and identification, but there is no requirement for FIPS-validated cryptography or continuous monitoring. If your cache only holds FCI, Level 1 may apply. Self-assessment is permitted. Most defense contractors, however, handle CUI, which means Level 1 is insufficient.

CMMC Level 2: Controlled Unclassified Information (CUI). 110 practices from NIST SP 800-171 Rev 2. This is where the majority of defense contractors land. CUI includes technical data, export-controlled information, personally identifiable information of military personnel, contract pricing, engineering specifications, logistics data, and dozens of other categories defined in the CUI Registry. Level 2 requires a third-party assessment by a CMMC Third-Party Assessment Organization (C3PAO) for contracts involving critical national security information. When CUI hits your cache -- and it does, every time your application caches a database query result containing any of these data types -- the cache must satisfy all 110 controls, the same as your database, your application servers, and your network infrastructure.

CMMC Level 3: CUI with Enhanced Protection. 134 practices: the 110 from SP 800-171 plus 24 enhanced controls from NIST SP 800-172. Level 3 applies to contracts involving the most sensitive CUI -- programs where a compromise would cause serious or exceptionally grave damage to national security. The assessment is government-led, conducted by the Defense Contract Management Agency (DCMA) with support from the Defense Counterintelligence and Security Agency (DCSA). The 24 enhanced controls focus on adversary sophistication: provenance tracking, anomalous behavior detection, system integrity verification, and penetration-resistant architectures. These are precisely the controls that require your cache to do more than store and retrieve bytes. Your cache must prove where values came from, detect unauthorized modifications, and verify its own integrity continuously.

The 14 NIST SP 800-171 Controls That Touch Cache

Not every NIST SP 800-171 control is relevant to cache infrastructure. Physical security controls, personnel screening requirements, and maintenance procedures apply to other parts of your system. But 14 controls map directly to what your cache does: store sensitive data, serve it to authorized (and potentially unauthorized) clients, and handle its lifecycle. Here is the complete mapping.

Control 3.13.11 is the one that eliminates most existing cache solutions immediately. FIPS-validated cryptography is not optional at Level 2 or Level 3. It is a binary requirement: either your cryptographic module has a FIPS 140-2 or 140-3 validation certificate, or it does not. Redis has no FIPS-validated cryptographic module. The TLS implementation in Redis uses OpenSSL, which can be FIPS-validated, but the data at rest in Redis memory has no cryptographic protection at all -- FIPS or otherwise.

Why Redis Cannot Pass CMMC Assessment

Redis is a fast, widely deployed in-memory data structure store. It is also categorically unable to satisfy CMMC Level 2 or Level 3 requirements. This is not a configuration issue. It is an architectural one. No amount of hardening guides or compliance wrappers changes the fundamental design decisions that make Redis incompatible with controlled environments.

No FIPS-validated cryptographic module. Redis has no built-in encryption at rest. Data in Redis memory is plaintext. There is no FIPS 140-2 or 140-3 validation certificate for any Redis cryptographic component because Redis does not perform cryptographic operations on cached data. Control 3.13.11 requires FIPS-validated crypto for all CUI protection mechanisms. Redis cannot satisfy this control. ElastiCache in GovCloud uses AWS-managed FIPS-validated encryption for the underlying storage layer, but the data in memory during processing remains plaintext, and there is no per-entry cryptographic integrity verification.

No per-key access controls. Redis ACLs, introduced in Redis 6, operate at the command level and key pattern level. You can restrict a user to GET commands on keys matching contract:*. You cannot enforce that the logistics service reads contract:pricing-2026 while the reporting service cannot. Controls 3.1.1 and 3.1.2 require access limited to authorized users performing authorized transactions. Redis AUTH is all-or-nothing within its pattern matching. A service authenticated for contract:* can read every contract cached in the system. There is no concept of data classification, CUI marking, or need-to-know enforcement at the cache entry level.

No audit logging of individual key access. Redis MONITOR logs every command to every connected client in real time. It also degrades throughput by 50% or more and is explicitly documented as unsuitable for production use. Redis SLOWLOG only records commands that exceed a latency threshold. Neither mechanism produces the audit trail required by controls 3.3.1 and 3.3.2: a retained log of every access to CUI, attributable to a specific identity, with timestamps, queryable for assessment purposes. Without production-grade audit logging, you cannot demonstrate to a C3PAO assessor that CUI in your cache was accessed only by authorized services.

No data classification or CUI marking. CMMC requires that CUI be marked and handled according to its classification. Redis has no metadata framework for entries. A cached value is bytes associated with a key. There is no way to tag a key as containing CUI, mark it with a specific CUI category, or enforce handling rules based on classification. Every entry is treated identically regardless of sensitivity.

No integrity verification. When you GET a value from Redis, you receive whatever bytes are stored at that key. There is no mechanism to verify those bytes are authentic and unmodified. If an attacker gains write access to the Redis instance -- through a compromised client, a network-level attack, or exploitation of a Redis vulnerability -- they can modify any cached CUI without detection. There are no checksums, no signatures, no tamper detection. Control 3.14.6 requires monitoring for unauthorized changes. Redis provides no mechanism for this at the data level.

CMMC Level 3: The Enhanced Controls

CMMC Level 3 adds 24 controls from NIST SP 800-172. These controls assume a sophisticated adversary -- a nation-state actor with significant resources and persistence. The enhanced controls do not just require that you protect CUI. They require that you detect, resist, and recover from advanced attacks on your infrastructure. Three of these enhanced controls are directly relevant to cache architecture, and they are precisely the controls where traditional caching solutions have no answer at all.

3.13.4e: Employ Provenance Tracking

SP 800-172 control 3.13.4e requires organizations to "employ provenance tracking for CUI." Provenance means the documented origin, chain of custody, and transformation history of data. For a cache, provenance answers the question: where did this cached value come from, what computation produced it, what inputs went into that computation, and has anything changed since?

This is exactly what Cachee computation fingerprints provide. Every cached entry has a fingerprint computed as SHA3-256(input || computation || parameters || version || hardware_class). This fingerprint is a provenance record. It cryptographically binds the cached value to the specific computation that produced it, including the software version that ran the computation and the hardware class it ran on. If any component of the provenance chain changes -- a different input, a patched algorithm, a new server -- the fingerprint changes, and the cached result is treated as a cache miss. The provenance is not metadata attached to the entry. It is the identity of the entry.

3.14.1e: Verify Integrity of Critical Systems

SP 800-172 control 3.14.1e requires organizations to "verify the integrity of critical software, firmware, and hardware components." For cache infrastructure, this means verifying that cached values have not been tampered with and that the cache system itself has not been compromised.

Cachee implements this through triple post-quantum signature verification. Every cache entry is signed by three independent algorithms: ML-DSA-65 (FIPS 204), FALCON-512 (NIST Round 3 winner), and SLH-DSA-SHA2-128f-simple (FIPS 205). Every cache read verifies all three signatures before returning the value. An attacker would need to simultaneously break MLWE lattices, NTRU lattices, and stateless hash functions -- three independent mathematical hardness assumptions -- to forge a cache entry that passes verification. Any single signature failure triggers immediate invalidation and incident logging. This is not a periodic integrity check. It is continuous, on every read, with zero additional configuration.

3.14.2e: Monitor for Anomalous Behavior

SP 800-172 control 3.14.2e requires monitoring organizational systems for anomalous behavior. For cache infrastructure, anomalous behavior includes unusual access patterns: a service suddenly reading cache keys it has never accessed before, a spike in cache misses that could indicate cache poisoning, or read patterns that suggest data exfiltration (sequential reads across an entire key space).

Cachee's computation fingerprint log enables this analysis. Because every cache operation is logged with the identity of the accessor, the key accessed, the operation type, and the timestamp, pattern analysis can detect anomalies in real time. A service that normally reads 50 keys per minute suddenly reading 5,000 is detectable. A client that only writes to pricing:* keys suddenly reading from engineering:* keys is detectable. The fingerprint log is the data source; your SIEM is the analysis engine.

Building a CMMC-Compliant Cache Architecture

A CMMC-compliant cache architecture is not a Redis instance with compliance wrappers. It is a fundamentally different design that treats every cached value as CUI from the moment it enters the cache. Here are the six architectural requirements and how they map to CMMC controls.

In-process cache deployment. An in-process cache runs inside the application's memory space. There is no network connection between the application and the cache. This eliminates the entire network attack surface: no TLS configuration, no network segmentation concerns, no encrypted-in-transit requirements, no network monitoring. The CUI boundary shrinks from "application + network + cache server" to "application." Fewer components in scope means fewer controls to implement, fewer evidence artifacts to produce, and a smaller attack surface for your assessor to examine. For defense contractors running on classified or air-gapped networks, in-process deployment eliminates the risk of cache traffic leaking across network boundaries entirely.

FIPS-validated PQ signatures. ML-DSA-65 is standardized as FIPS 204. Every cache entry signed with ML-DSA-65 uses a FIPS-validated algorithm. This satisfies control 3.13.11 (FIPS-validated crypto) at the cache entry level, not just the transport level. The signature protects the cached value itself, not just the channel it travels over. This is a critical distinction for assessors: volume-level encryption (ElastiCache) protects against physical access. Entry-level PQ signatures protect against application-level attacks, compromised clients, and insider threats.

Owner/Regulator/Auditor key hierarchy. The three key types map directly to CMMC roles. Owner keys are held by the application services that read and write CUI to the cache. Regulator keys are held by the Information System Security Officer (ISSO) and compliance staff -- they can query cache metadata, verify signatures, and inspect the fingerprint log without reading the cached CUI values. Auditor keys are provided to the C3PAO or DCMA assessment team -- they enable zero-knowledge verification that controls are operating without granting access to the CUI itself. This separation satisfies controls 3.1.1 (authorized access), 3.1.5 (least privilege), and 3.3.2 (traceable actions) simultaneously.

Computation fingerprint as provenance chain. Every cached value is bound to a SHA3-256 fingerprint of its computational origin. The fingerprint includes the input data hash, the computation type, the algorithm parameters, the software version, and the hardware class. This creates a provenance chain for every value in the cache. When an assessor asks "where did this cached value come from and how do you know it has not been modified," the fingerprint is the answer. It satisfies SP 800-172 control 3.13.4e (provenance) and SP 800-171 control 3.14.6 (monitoring) in a single mechanism.

Lifecycle state machine with controlled disposal. Every cache entry follows a four-state lifecycle: Active, Superseded, Revoked, and Expired. Every transition requires a TransitionAuthority (which key authorized the change) and produces a TransitionProof (cryptographic proof of the transition). Revocation and expiration trigger memory sanitization -- the entry is zeroized, not just freed. This satisfies control 3.8.3 (media sanitization) and ensures that evicted CUI is not recoverable from memory. The transition log provides the evidence artifact for change management.

CUI classification metadata. Each cache entry can carry classification metadata: CUI category, dissemination control, and handling instructions. The cache enforcement layer uses this metadata to restrict access based on the client's authorization level. A service authorized for CUI//SP-EXPT (export-controlled) can read entries marked with that category. A service authorized for CUI//SP-CTI (controlled technical information) cannot read SP-EXPT entries even if it has a valid Owner key. This is the per-entry access control that Redis cannot provide.

# cachee.toml — CMMC Level 3 compliance configuration

[attestation]
enabled = true
algorithms = ["ML-DSA-65", "FALCON-512", "SLH-DSA-SHA2-128f"]
fingerprint_hash = "SHA3-256"
fingerprint_fields = ["input", "computation", "parameters", "version", "hardware_class"]
fips_mode = true  # enforce FIPS 204 ML-DSA-65 as primary

[access_control]
key_types = ["Owner", "Regulator", "Auditor"]
auditor_zk_queries = true
enforce_separation_of_duties = true
cui_classification_required = true
cui_categories = ["SP-CTI", "SP-EXPT", "SP-PRVCY", "SP-PROCURE"]

[state_machine]
states = ["Active", "Superseded", "Revoked", "Expired"]
require_transition_authority = true
require_transition_proof = true
log_all_transitions = true
zeroize_on_eviction = true  # CMMC 3.8.3 media sanitization

[audit]
fingerprint_log = "/var/log/cachee/fingerprints.log"
transition_log = "/var/log/cachee/transitions.log"
rotation_log = "/var/log/cachee/key-rotations.log"
cab_output_dir = "/var/lib/cachee/cab-bundles/"
retention_days = 2190  # 6 years per DFARS 252.204-7012

[contracts]
default_freshness_ms = 30000
strict_mode = true  # return miss on stale, never serve expired

[encryption]
transit = "mTLS"
tls_min_version = "1.3"
in_process_mode = true  # no network transit for CUI

[key_rotation]
interval_days = 90
auto_rotate = true
re_sign_on_rotation = true

[anomaly_detection]
enabled = true
baseline_window_hours = 168  # 7-day rolling baseline
alert_threshold_multiplier = 10  # alert at 10x normal access rate
siem_export = true
siem_format = "CEF"  # Common Event Format for Splunk/ArcSight

This configuration enables all 14 base controls and the three enhanced controls. The fips_mode flag ensures ML-DSA-65 (FIPS 204) is the primary signature algorithm. The cui_classification_required flag enforces that every cache entry must carry a CUI category. The zeroize_on_eviction flag ensures media sanitization. The retention_days is set to 2,190 (six years) to satisfy DFARS 252.204-7012 retention requirements. The anomaly_detection section enables the access pattern analysis required by SP 800-172 control 3.14.2e.

Assessment Preparation: Evidence Your Assessor Needs

A CMMC assessment is evidence-driven. Your assessor -- whether a C3PAO for Level 2 or DCMA for Level 3 -- needs to see specific artifacts that demonstrate your controls are implemented, operating effectively, and producing the expected outcomes. Saying "we use encrypted caching" is not evidence. Handing the assessor a Cache Attestation Bundle they can independently verify is evidence. Here is what you need.

System Security Plan (SSP) Entries for Cache

Your SSP must include cache infrastructure as a system component. For each of the 14 applicable controls, the SSP must describe how the cache satisfies the control, what evidence is produced, and where the evidence is stored. A common failure is listing the database and application servers in the SSP while omitting the cache entirely. Your assessor will ask about every data store in your boundary. If the cache is not in the SSP, it is either out of scope (which means CUI must never enter it -- good luck enforcing that) or it is an SSP gap (which is a finding).

Plan of Action and Milestones (POA&M)

If your current cache infrastructure has gaps -- and if you are running Redis, it has 14 gaps -- the POA&M documents each gap, the remediation plan, the responsible party, and the target completion date. CMMC allows limited POA&M items, but they must be closed within 180 days. A POA&M entry that says "migrate from Redis to CMMC-compliant cache" with a 90-day timeline is far better than an assessor discovering an undocumented Redis instance holding CUI with no controls.

Evidence Artifacts

The following artifacts map directly to NIST SP 800-171A assessment objectives.

CAB bundles (Cache Attestation Bundles). Each CAB is a self-contained verification package: the cached value (encrypted), all three PQ signatures, the computation fingerprint, the state transition history, and the public keys. An assessor takes a CAB, runs the verification tool offline, and confirms that the entry is authentic, unmodified, and properly classified. No access to the live cache is required. The CAB is portable, offline-verifiable evidence.

Computation fingerprint logs. Append-only logs covering the entire assessment period. Each entry: fingerprint hash, timestamp, operation type (read/write/hit/miss/evict), accessor identity, CUI category, and result. These logs satisfy 3.3.1 (audit records) and 3.3.2 (traceable to individual users). The assessor can query the log to verify that CUI was accessed only by authorized services during the assessment period.

Key rotation records. Documentation of every key rotation event: date, key type (Owner/Regulator/Auditor), old key fingerprint, new key fingerprint, re-signing status. These records satisfy 3.13.11 (FIPS crypto management) and demonstrate that cryptographic material is managed according to policy.

State transition history. Complete log of every entry lifecycle change: creation, supersession, revocation, expiration. Each transition includes the TransitionAuthority, TransitionProof, and timestamp. This satisfies 3.8.3 (controlled disposal) by proving that revoked and expired CUI was properly sanitized.

Anomaly detection reports. For Level 3, the assessor needs evidence that anomalous cache access patterns are detected and investigated. Export the anomaly detection alerts from the assessment period, along with the incident response records for any alerts that were triggered. This satisfies SP 800-172 control 3.14.2e.

The Subcontractor Problem

CMMC does not stop at the prime contractor's boundary. DFARS 252.204-7012 requires that CUI protection requirements flow down to every subcontractor that handles CUI. If you are a prime contractor and your subcontractors cache CUI -- in their development environments, their testing systems, their production infrastructure -- their cache must meet the same CMMC level as yours. This is the flow-down problem, and it is where cache compliance becomes exponentially harder.

A prime contractor might have five subcontractors, each running their own Redis instances, each caching CUI from shared data feeds. The prime's SSP must account for the CUI data flow to each sub. Each sub must have their own SSP entries for cache. Each sub must produce evidence artifacts. If one sub's Redis instance is unencrypted and unaudited, the prime's CMMC assessment is at risk.

In-process cache architecture simplifies this dramatically. When the cache runs inside the application process, there is no shared cache infrastructure between prime and subcontractors. There is no Redis cluster that multiple organizations connect to. Each application instance has its own cache, its own keys, its own fingerprint log, and its own evidence artifacts. The CUI boundary is the application, not the network. Flow-down requirements still apply to the application itself, but the cache is no longer a shared infrastructure component that creates cross-organizational compliance dependencies.

For subcontractors who lack the engineering resources to build CMMC-compliant cache infrastructure from scratch, an in-process cache with native CMMC controls is the fastest path to compliance. Deploy the library, configure the TOML file, and the cache produces CMMC evidence artifacts from day one. No Redis cluster to harden. No compliance wrappers to build. No FIPS-validated encryption layer to integrate. The controls are the cache.

The Bottom Line

CMMC is not a future requirement. It is a current one. Every DoD contract with DFARS 252.204-7012 already requires NIST SP 800-171 compliance, and CMMC adds the assessment and enforcement mechanism. Cache infrastructure that holds CUI is in scope for all 14 applicable controls at Level 2 and all 14 plus three enhanced controls at Level 3. Redis has no FIPS-validated cryptographic module, no per-key access controls, no production-grade audit logging, no integrity verification, no data classification, and no provenance tracking. It cannot pass a CMMC assessment at any level above Level 1.

The architecture that passes CMMC assessment is one where compliance is not an add-on but a property of the cache itself. FIPS-validated PQ signatures on every entry. Computation fingerprints as provenance records. Owner/Regulator/Auditor key separation. Lifecycle state machines with transition proofs. Memory sanitization on eviction. CUI classification enforcement at the entry level. Anomaly detection from the fingerprint log. These are not features you enable. They are the cache.

Your database passes CMMC because it was built for controlled environments. Your application servers pass because you hardened them according to STIGs. Your network passes because you segmented it and monitor it. Your cache is the gap. It holds the same CUI as every other component in your system, but it has none of the controls. Your assessor will find it. The question is whether they find a Redis instance with no controls or a cache that produces CAB bundles, fingerprint logs, and transition proofs as naturally as it serves cache hits.