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.

tiCrypt delegates VM storage to libvirt storage pools, but not every pool type can create volumes on demand. This article explains which pool types support dynamic provisioning and how encrypted data drives map onto network block-device backends like Ceph RBD and iSCSI.

On June 18, 2026, tiCrypt gets its first major visual update in a few years. The redesigned front-end (v2.17.0) will be available from the Tera Insights repository, and this release is dedicated entirely to one thing: the experience.

We listened to feedback from researchers and administrators across our deployments and rebuilt the interface around how you actually work, while leaving everything beneath it untouched. There is no migration and nothing new to learn; every workflow, process, and security mechanism is exactly as it was.

What is new

• A true dark mode, alongside a refined light mode
• Cleaner iconography for faster recognition across the platform
• Better use of space, so screens feel less crowded
• Flexible layouts that bring the most relevant details to the front

What is next

This release is a starting point. As more researchers share feedback, we will continue to adapt and improve. This redesign also lays a long-term UX foundation for building much larger features.

Getting the update

Front-end v2.17.0 ships June 18, 2026, from the Tera Insights repository. Administrators can pull the latest release to roll it out across their deployment. For deployments that pull directly from the Tera Insights repository, users will automatically receive the update when they launch the application.

How tiCrypt's client-side encryption, key isolation, and PKI enable a shared file system to host a CUI enclave.

tiCrypt VM Installer 3.10.42 establishes the new baseline for all tiCrypt deployments. Older versions won't support certain upcoming VM Controller features. This release introduces native SLURM integration and a new admin access control model.

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.

Federal research funding at U.S. universities reached $64 billion in FY 2024. A growing share of that money now requires the receiving institution to handle data inside a compliant secure enclave. Institutions that do not have one cannot bid on the contracts, cannot access the datasets, and cannot participate in the collaborations. The funding does not go away. It goes to institutions that are ready.

This is not a future problem. CMMC Phase 1 is in effect. NIH's NIST 800-171 requirement for controlled-access data took effect in February 2026. The FAR proposed rule will extend the same requirements to every federal executive agency. Universities that have not invested in a secure research enclave are already losing ground.

REDCap is a widely used platform for building and managing online surveys and databases. It serves two fundamentally different roles:

1. Data collection: REDCap collects responses from patients, research participants, or other users through its survey interface, storing submissions in a secure database.
2. Data management and analysis: Authorized users access the REDCap server and database directly to clean, analyze, and report on collected data, often exporting it to other tools for further processing.

This article focuses on enabling external data collection while securing the REDCap server and database with tiCrypt. Data management and analysis are straightforward since authorized users can work inside secure VMs in tiCrypt. The overarching goal is to achieve CMMC Level 2 compliance with reasonable effort and no security or compliance risks.