Skip to main content

Encrypted CUI Is Still CUI: Where tiCrypt Fits in the Latest CMMC and NIST Guidance

· 12 min read
Thomas Samant
Thomas Samant
Senior Partner

Compliance guidance is not supposed to be a fast-moving field. The last twelve months did not get the memo. Since November 2025, CMMC went live in contracts, its FAQ was revised four times, and its second phase was suspended before it began. Along the way the Department of Defense settled a question that our own documentation had answered differently. We have now brought the whitepaper, the System Security Plan, the control guides, and the articles up to date. Some of those updates arrived later than we would have liked. The ground kept moving while we were writing, and we were shipping major releases at the same time, with new security capabilities and features across the product. This is our account of what changed and where tiCrypt stands.

For years, a common reading of the CUI rules held that strongly encrypted data could be stored anywhere, because whoever held the storage could not read it. We made that argument ourselves, and in past assessments we made it successfully: without the keys, tiCrypt's ciphertext is noise, and it cannot be told apart from random data or from anything else on the same storage. That is still true as a matter of cryptography. It is no longer the test. The Department of Defense CIO has now answered the question in writing, and the answer is no: encrypted CUI is still CUI. The designation follows the information, not whether anyone can read it. The system that stores the ciphertext is in the assessment scope, a cloud service that stores it must meet FedRAMP Moderate, and encryption alone does not separate one environment from another.

This does not weaken the case for client-side encryption. It changes what the encryption is credited with. tiCrypt's encryption still carries the confidentiality requirements for file and drive content, and it shortens the rest of the work: backups of that content need no encryption of their own, they can go to the compliant backup system your central IT already operates, and destroying every copy of a resource's key erases it wherever its ciphertext was copied. This article covers what the guidance says, what tiCrypt provides, and what your organization decides.

What the Guidance Says​

The source is the CMMC Frequently Asked Questions published by the Department of Defense CIO. Four answers in the July 2026 edition matter here.

QuestionAddedAnswer
B-Q8: Is encrypted CUI still considered to be CUI?November 2025Yes. "Encrypted CUI data retains the control designation given to the plain text counterpart." A sentence added in April 2026 accepts cryptographic erase for sanitizing media when it is implemented in accordance with NIST SP 800-88.
E-Q2: Can a cloud service offering that is not FedRAMP Moderate store encrypted CUI?November 2025"No." The contractor must ensure the provider "meets security requirements equivalent to those established for the FedRAMP Moderate baseline."
F-Q3: Can encryption alone create logical separation for a network within a CMMC Assessment Scope?January 2026"No." Logical separation comes from software or network controls such as firewalls, routers, VPNs, and VLANs. Encryption "does not, by itself, prevent data transfer or enforce the security boundary of a network."
F-Q4: Must enterprise networking components that carry an enclave's encrypted CUI be brought into the enclave's scope?January 2026"No," as long as the enclave is otherwise logically separated from the enterprise network.

These are answers, not new rules. B-Q8 rests on 32 CFR Part 2002, the government-wide CUI rule, under which CUI stays controlled until it is formally decontrolled. E-Q2 applies the cloud requirement that DFARS 252.204-7012 already places on contractors. The FAQ puts in writing what the Department of Defense considers those rules to have required all along.

Where the standards stand​

  • NIST SP 800-171 Revision 3 makes backup cryptography explicit: Requirement 03.08.09 requires protecting the confidentiality of backup information and implementing cryptographic mechanisms to prevent unauthorized disclosure of CUI at backup storage locations. Requirement 03.13.08 does the same for CUI in transmission and in storage.
  • CMMC Level 2 is still assessed against Revision 2: FAQ question B-Q3 states that the Department of Defense will incorporate Revision 3 through future rulemaking and assesses against Revision 2 until then. The Revision 2 counterpart is requirement 3.8.9, CMMC practice MP.L2-3.8.9.
  • The Phase 2 transition is suspended, the safeguarding requirements are not: The July 2026 edition records that the Department of Defense "has suspended the transition to Phase 2 of the program" while it reviews the program. Phase 1 self-assessment requirements remain in place, and NIST SP 800-171 and DFARS 252.204-7012 are contract requirements that continue to apply.

Neither revision of NIST SP 800-171 says whether ciphertext is CUI. That question belongs to the CUI rule, which applies to every executive branch agency. Plan for the same reasoning from any sponsor that requires NIST SP 800-171, not only from the Department of Defense.

What Does Not Change: The Security​

tiCrypt encrypts file and drive content before it reaches storage, and the server never holds a key that can decrypt it.

  • Per-resource keys: Every file and every drive has its own AES-256 key.
  • Keys held by users: Each resource key is wrapped with the RSA-2048 public key of every authorized user. Private keys are never available to the server in usable form. The only server-side copy is the optional escrow copy, which is encrypted and can be recovered only by the escrow groups acting together. Administrators and storage operators cannot decrypt what they manage.
  • Encrypted drives: VM drives are encrypted inside the VM, with LUKS on Linux and BitLocker on Windows. The VM host, the backend, and the storage system have no access to the drive key.
  • Validated cryptography: tiCrypt protects CUI with the OpenSSL 3.1.2 FIPS provider (CMVP certificate #4985, validated under FIPS 140-3), on the user's client and in the VM controller, and implements no cryptography of its own. Drive encryption runs inside the VM with the operating system's FIPS mode enabled, on that operating system's validated modules.
  • Tamper-evident audit: File access, key operations, and transfers are recorded in a hash-chained audit trail.

The result is the property that matters most in a breach: a stolen disk, a copied backup, or a compromised storage account yields file and drive content only as ciphertext, with no usable key. The one exception is metadata. File and directory names in the platform database are not encrypted, so keep CUI out of them.

The guidance takes nothing away from this. It says that confidentiality is one requirement among several, and that protecting the data does not decide where the data may be kept.

What Changes: Where the Ciphertext May Live​

Three questions that used to be answered with "it is encrypted" now need an answer of their own.

  • Backups: A backup of encrypted CUI is CUI. The system that holds it is in your assessment scope.
  • Cloud: Under a Department of Defense contract, a cloud service that holds the ciphertext must meet the FedRAMP Moderate baseline or its equivalent, whether or not it ever holds a key.
  • Shared infrastructure: Storage and networks shared with other workloads need logical separation built from network and access controls. Encryption does not provide it.

A backup system cannot tell which encrypted chunks are CUI, and it does not need to. Under the CMMC Level 2 scoping guidance, an asset that stores CUI is a CUI Asset, so the whole backup set from a deployment that holds CUI is handled as CUI.

How tiCrypt Closes the Gap​

What the guidance asks forWhat tiCrypt providesWhat your organization does
Confidentiality of backup CUI (MP.L2-3.8.9, Rev 3 03.08.09)Vault chunks and drive images are ciphertext before they reach storage, and no decryption key is stored on the infrastructure. Any backup of them meets the cryptographic requirement with no backup-side encryption or key management.Keep the backup target inside the assessment scope. Keep CUI out of file and directory names, and protect the database backup with your own controls, because tiCrypt does not encrypt it.
Validated cryptography (SC.L2-3.13.11)The backup of Vault and drive content is protected by the same FIPS-validated cryptography as the live data.Vault and drive content does not depend on the backup product's encryption. If you use that encryption to protect the database backup, it must be FIPS-validated.
Sanitization (MP.L2-3.8.3, FAQ B-Q8)Each resource has its own key. Destroying every copy of the key cryptographically erases the resource wherever its ciphertext was copied, including backup media that are hard to reach.Confirm every copy of the key is gone: the live copy is removed when the deleted file is purged, and database backups, which hold wrapped keys, must expire and be sanitized from the backup media. Sanitize physical media and the unencrypted metadata under your NIST SP 800-88 procedures.
Logical separation (FAQ F-Q3)Secure VMs run on isolated networks that deny outbound traffic by default, and all access passes through the backend as a single enforcement point.Operate the external firewall and VLANs around the tiCrypt hosts, and restrict the storage exports and the backup pool to those hosts.
Transport to the backup target (SC.L2-3.13.8 over the network, MP.L2-3.8.6 for media carried off site, FAQ F-Q4)File and drive content is ciphertext before it leaves the enclave.Encrypt the database backup in transit, and keep tapes under your media-handling procedures. Enterprise network equipment that only carries properly encrypted traffic stays out of scope when the enclave is otherwise logically separated.
Limiting access (AC.L2-3.1.1, MP.L2-3.8.2)Backup and storage operators cannot decrypt the file and drive content they handle.Authorize and limit operator accounts on the backup system. Those operators administer systems that store CUI, so screening and training requirements apply to them.

Use the backup system you already have​

tiCrypt stores Vault content as ordinary files in a directory and drives as image files (raw or QCOW2) in storage pools. There is no proprietary backup format, agent, or plug-in. The backup product your central IT already operates inside an assessed boundary can take tiCrypt's storage as it is, through file-level backup, storage snapshots, replication, or tape.

That turns the guidance into a placement decision instead of a new project, provided the backup system is already inside an assessed boundary. A CUI Asset is assessed against all Level 2 requirements, so a backup system that has not been assessed must first be brought to that standard.

  • Central IT backup inside your assessed boundary: Give tiCrypt a pool or tenant of its own, reachable only from the tiCrypt hosts, and add it to the SSP. No second backup system is needed.
  • A backup target inside the tiCrypt enclave: This keeps the scope smallest, at the cost of operating the target yourself.
  • A cloud backup service: This is acceptable when the service is FedRAMP Moderate authorized or meets the Department of Defense's equivalency requirements, and when the provider also meets the obligations in DFARS 252.204-7012 paragraphs (c) through (g): cyber incident reporting, malicious software, media preservation, access for forensic analysis, and damage assessment.

In each case the people who run the backups never hold a usable key. If a tape is lost or a backup account is compromised, file and drive content is exposed only as ciphertext. A copy of the database backup would also expose file and directory names.

A Backup Design That Holds Up at Assessment​

  1. Back up three things from the same point in time. Back up the Vault chunk directory, the drive pools, and the platform's MongoDB databases. The databases hold the wrapped keys, so neither chunks nor drives can be restored without them. Include the audit log and the service configuration.

  2. Protect the database backup conventionally. In addition to wrapped keys, the databases contain file and directory names, which are not encrypted.

  3. Separate and mark the backup pool. Use a dedicated pool or tenant, restricted to the tiCrypt hosts, and mark it as CUI.

  4. Record it. List the backup target in the asset inventory as a CUI Asset, document its treatment in the SSP, and show it in the network diagram of the assessment scope and in your data flow diagram.

  5. Set retention on purpose. Cryptographic erase is complete when the last copy of a key is gone: the live copy when the deleted file is purged, and the copies in old database backups when those backups have expired and been sanitized from the backup media. Expiry alone only takes a backup off the schedule. Cryptographic erase does not remove file and directory names.

  6. Keep recovery working. A restore is only useful while users' private keys survive, and those live in key files on their own devices, not in the server backup. Where your policy allows it, maintain key escrow. Where it does not, recovery depends on users' own key-file backups. Test a restore.

Encryption decides who can read the data. Scope decides which systems you must account for. tiCrypt settles the first question at the cryptographic layer and leaves the second as a decision about where each copy lives.

Further Reading​