CMMC Level 2 requires organizations to satisfy 110 security practices defined in NIST SP 800-171 Revision 2 across 14 control families. tiCrypt's compliance model splits these practices into three responsibility categories.
Organizations operating research clusters, HPC environments, and open compute infrastructure already maintain filesystems measured in petabytes. When CMMC Level 2 compliance enters the picture, organizations often assume CUI requires physically dedicated storage: a separate appliance, separate drives, a hard boundary between the regulated enclave and everything else. That assumption is expensive and, under tiCrypt's architecture, unnecessary.
tiCrypt's client-side encryption reduces the storage layer to a ciphertext-only medium. The filesystem never holds keys or plaintext. Because the storage layer cannot read what it stores, CUI can share physical media with non-CUI workloads without compromising confidentiality. You can carve out a partition, directory, or namespace on your existing shared filesystem, point tiCrypt at it, and maintain full CMMC L2 compliance without purchasing dedicated hardware. This article explains how to do it, what the storage layer actually holds, and which CMMC controls make this acceptable.
For the theoretical foundation behind cryptographic isolation on shared media, see Cryptographic Isolation for CUI on Shared Storage. For details on how tiCrypt interacts with the underlying filesystem, see Interplay between the filesystem and tiCrypt.
If you are preparing for a CMMC Level 2 assessment, the Audit and Accountability (AU) control family is one of the first areas an assessor will examine. The nine AU practices in NIST SP 800-171r2 (practices 3.3.1 through 3.3.9) require your organization to demonstrate that every action involving Controlled Unclassified Information (CUI) is logged, attributable to a specific user, protected from tampering, and available for review. tiCrypt's audit system addresses these requirements.
This article is written for compliance officers and audit program managers building a System Security Plan (SSP) and preparing evidence packages for CMMC Level 2 assessment. It covers what tiCrypt's audit system captures and flags, how the architecture works and connects to your SIEM, where the platform's responsibility ends and your organizational controls must begin, and how each AU practice maps to specific capabilities and evidence. For a deeper look at the audit schema and forensic investigation capabilities, see Usage Reporting and Forensics in tiCrypt Audit.
We are often asked about the quantum computing threat to RSA. Adversaries may already be harvesting encrypted traffic for future decryption, NIST has finalized post-quantum standards, and NSA's CNSA 2.0 timeline calls for transition by 2030. What is tiCrypt doing about it?
Rather than keep this answer in inboxes, we are putting it on the record.
How tiCrypt's client-side encryption, key isolation, and PKI enable a shared file system to host a CUI enclave.
Universities evaluating cloud platforms for regulated research typically start with a reasonable assumption: the cloud provider handles security, and the institution handles research. The shared responsibility model promises exactly this. The provider secures the infrastructure. The customer secures everything running on it.
In practice, "everything running on it" includes most of the controls that NIST SP 800-171 actually requires. Access management, audit logging, session isolation, media protection, incident response, and configuration management all remain the customer's responsibility. The provider secures the rack. The institution must still secure the research.
This is not a criticism of cloud platforms. It is a description of the model. The problem is that many institutions adopt cloud-based research environments believing they have purchased compliance, when what they have purchased is infrastructure.
Secure virtual machines in tiCrypt run in near-complete isolation from each other and from the surrounding environment. This isolation is the foundation of tiCrypt's security model. Every network pathway into or out of a VM is tightly controlled, authenticated, and encrypted, with no exceptions.
This post explains the mechanisms that make this possible: proxy-mediated communication, application port tunneling, VM-level network isolation, and controlled access to external licensing servers.
Security isn't just about having the right tools. It's about how you use them.
Multi-Factor Authentication has become a cornerstone of modern cybersecurity. Whether you're chasing CMMC compliance, meeting NIST standards, or simply trying to keep bad actors out, MFA is table stakes. Duo, Shibboleth, NetID — these tools are everywhere, and for good reason: they work.
So why does tiCrypt refuse to trust them?