Shared Responsibility in Secure Compute

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.

How Responsibilities Are Divided

Category	Count	Description
Tera Insights / tiCrypt	74	Structural properties of the platform: cryptographic enforcement, immutable boot images, tamper-evident audit, deny-all network policy. The platform produces the evidence artifacts a C3PAO needs during assessment.
Jointly Managed	11	Controls where tiCrypt provides the tooling, data, or templates, but the deploying organization must drive the process. Tera Insights participates actively in these areas.
Organization	25	Controls that require institution-specific policies, physical infrastructure, or personnel processes—inherently about people, facilities, and organizational governance.

tiCrypt directly addresses 74 practices and jointly manages another 11 with your organization, for 85 of the 110 controls met together, leaving 25 that are inherently organizational.

Responsibility Matrix

110 practices across 14 control families (NIST SP 800-171r2)

Responsibility designations based on tiCrypt architectural analysis against NIST SP 800-171 Revision 2.

---

Access Control (AC)

16 tiCrypt Managed1 Jointly Managed5 Organization

Access Control is the largest family with 22 practices. tiCrypt handles 16 through cryptographic enforcement and architectural constraints, with publicly accessible content control (3.1.22) jointly managed. The remaining 5 are organizational because they govern wireless networks, mobile devices, and portable storage, areas outside the tiCrypt boundary.

tiCrypt Managed

tiCrypt's access control is cryptographic, not configurable. Users authenticate via RSA-2048 challenge-response signatures. The server never holds passwords or decryption keys. Access to CUI requires possession of both a valid key file and the correct password. Administrators cannot bypass this, even with full infrastructure access, because the server operates on data it cannot decrypt.

Practice	Name	How tiCrypt Satisfies It
3.1.1	Authorized Access Only	Users authenticate via RSA key pair. Access requires a valid key file plus password. No backdoor access path exists.
3.1.2	Transaction & Function Limits	Permission profiles define allowed actions across 10+ categories. Each action is checked against the user's assigned profile, which administrators can override with per-user custom permissions.
3.1.3	CUI Flow Enforcement	All data flows through the Vault's encryption layer. Files are split into 8 MB chunks, each encrypted with a unique AES-256 key on the client. Transfers between Vault and VMs are logged and audited.
3.1.4	Separation of Duties	Four privilege tiers (User, Sub-Admin, Admin, Super Admin) provide scoped visibility at each level. Administrators cannot access user data. Cryptographic separation ensures no single tier can both manage the system and read its contents.
3.1.5	Least Privilege	Permission profiles grant only the specific actions required. Users with no VM permissions cannot access VM features. Users removed from all teams are automatically deactivated.
3.1.6	Non-Privileged Accounts	Administrative actions require explicit role elevation. Standard user accounts cannot access management functions.
3.1.7	Privileged Function Execution	All privileged operations are logged in the tamper-evident audit trail with the executing user's identity.
3.1.8	Unsuccessful Logon Attempts	The system locks accounts after a configurable number of failed login attempts (default: 5). Account lockout is indefinite until administrator intervention.
3.1.9	Privacy & Security Notices	A configurable login banner and system notices are displayed before authentication.
3.1.10	Session Lock	The system enforces a configurable inactivity timeout. The session lock timer runs client-side with automatic key purge from memory.
3.1.11	Session Termination	The system automatically terminates sessions after a configurable timeout. Encryption keys are purged from memory on logout.
3.1.12	Remote Access Monitoring	All remote sessions are authenticated through the tiCrypt proxy and logged. No direct SSH or console access to VMs is possible.
3.1.13	Cryptographic Remote Access Protection	All connections use TLS transport with an additional Diffie-Hellman session key layer. The result is a double-encrypted channel between client and VM.
3.1.14	Managed Access Control Points	All traffic routes through the tiCrypt backend as a single enforcement point. VMs have deny-all outbound policy with explicit allowlists.
3.1.15	Remote Privileged Commands	All privileged commands executed remotely are authenticated and logged through the same proxy channel.
3.1.20	External System Connections	Outbound connectivity is denied by default. Licensing servers and external endpoints require explicit firewall rules.

Jointly Managed

Practice	Name	tiCrypt Provides	Your Organization Must
3.1.22	Publicly Accessible Content Control	The tiCrypt environment exposes no publicly accessible content; all access requires authenticated, key-based login.	Designate the personnel authorized to post to any public systems outside the enclave, and review that content to ensure no CUI is released.

Organization Managed

These controls address wireless access, mobile devices, and portable storage at the physical network level, outside the tiCrypt boundary.

Practice	Name	What Your Organization Must Do
3.1.16	Wireless Access Authorization	Establish policies governing who can use wireless networks in CUI-processing areas. Document authorization procedures.
3.1.17	Wireless Access Protection	Implement WPA3 or equivalent encryption on all wireless networks in the CUI boundary. Monitor for rogue access points.
3.1.18	Mobile Device Connection Control	Define which mobile devices (phones, tablets) can connect to systems that process CUI. Implement MDM or equivalent controls.
3.1.19	Mobile Device CUI Encryption	Require full-device encryption on any mobile device that stores or accesses CUI.
3.1.21	Portable Storage on External Systems	Establish policies restricting CUI on USB drives and portable media connected to external (non-tiCrypt) systems.

---

Awareness and Training (AT)

3 Organization

All three AT practices are organizational responsibilities. tiCrypt is a technical platform and cannot train your personnel or establish awareness programs.

Organization Managed

Practice	Name	What Your Organization Must Do
3.2.1	Security Awareness	Provide security awareness training to all system users, covering recognition of social engineering, phishing, and CUI handling requirements. Document training completion and frequency.
3.2.2	Role-Based Training	Deliver role-specific training to administrators, security officers, and users with elevated access. tiCrypt administrators should understand permission profiles, escrow procedures, and audit log review.
3.2.3	Insider Threat Awareness	Include insider threat indicators in awareness training. Cover data exfiltration indicators, behavioral red flags, and reporting procedures.

---

Audit and Accountability (AU)

8 tiCrypt Managed1 Jointly Managed

Every significant action in tiCrypt generates a tamper-evident log record. Each record incorporates the SHA-256 hash of the previous record, creating a hash chain where any modification to any record is cryptographically detectable. The audit system is deployed independently of the backend on a one-way TCP connection (port 25000) with no return path, preventing an attacker who compromises the backend from altering audit data.

tiCrypt Managed

Practice	Name	How tiCrypt Satisfies It
3.3.1	Audit Log Creation & Retention	The system captures 150+ event types across six categories (Sessions/Auth, File System, VMs, Virtual Drives, Files, Access Control). Logs are retained indefinitely. Logging is always on and cannot be disabled.
3.3.2	User Action Traceability	Every action is attributed to a specific authenticated user with millisecond-precision UTC timestamps. The hash chain ensures traceability cannot be retroactively altered.
3.3.4	Audit Processing Failure Alerts	The system issues real-time alerts with five severity levels (Info, Low, Medium, High, Critical) for automated detection of security events.
3.3.5	Audit Record Correlation	The ClickHouse columnar database enables high-performance correlation across event types, users, time ranges, and resource types.
3.3.6	Audit Reduction & Report Generation	The TOML-based query builder supports parameterized queries, autocomplete, SQL generation, chart visualization, and Excel export.
3.3.7	Clock Synchronization	All components use UTC timestamps at millisecond precision.
3.3.8	Audit Information Protection	The SHA-256 hash chain makes any record modification detectable. The one-way TCP push architecture prevents return-path attacks.
3.3.9	Audit Management Restriction	Audit system access is restricted to authorized administrators. Audit data cannot be modified or deleted through the application.

Jointly Managed

Practice	Name	tiCrypt Provides	Your Organization Must
3.3.3	Audit Event Review & Updates	tiCrypt provides complete audit data, query tools, severity-based alerting, and report generation.	Establish a regular review cadence. Assign personnel to review audit logs, investigate alerts, and update audit event definitions as the threat landscape evolves.

See Satisfying CMMC Level 2 Audit and Accountability Controls with tiCrypt for a detailed breakdown of all nine AU practices.

---

Configuration Management (CM)

8 tiCrypt Managed1 Organization

tiCrypt eliminates configuration drift by design. Security controls are structural properties of the architecture, not configurable settings that can be weakened. VM images are immutable and reset on every boot. Network policy is deny-all by default. Encryption is mandatory and cannot be disabled.

tiCrypt Managed

Practice	Name	How tiCrypt Satisfies It
3.4.2	Security Configuration Settings	Security settings are architectural, not configurable. Encryption, session isolation, and network deny-all are not optional. System settings are managed through the Management Console with full change tracking.
3.4.3	Change Tracking & Approval	The System Settings History records every settings change with the previous value, new value, timestamp, and administrator identity.
3.4.4	Security Impact Analysis	Changes to permission profiles, team quotas, and project access are enforced through the Management Console with audit logging.
3.4.5	Access Restrictions for Changes	Changes to tiCrypt-level configuration are restricted to designated administrators through Permission Profiles, and every change is captured in the tamper-evident audit trail. Signed components and reset-on-boot images prevent unauthorized persistent modification. The organization retains physical access restrictions to the host infrastructure.
3.4.6	Least Functionality	VMs run on immutable boot images with no persistent state. Only explicitly allowed software persists on encrypted drives. Outbound network access is denied by default.
3.4.7	Nonessential Program Restriction	VM images contain only the operating system and the tiCrypt VM Installer. Additional software must be explicitly installed by the administrator in a service VM and baked into a new image.
3.4.8	Software Execution Policy	The VM Controller manages the software execution environment. Users cannot modify the boot image or install persistent software outside encrypted drives.
3.4.9	User-Installed Software Control	Software installed by users does not survive VM reboot. Only administrator-approved software in the base image persists across sessions.

Organization Managed

Practice	Name	What Your Organization Must Do
3.4.1	Baseline Configurations & Inventories	Maintain a documented baseline configuration for the tiCrypt deployment (version, settings, VM images in use) and a hardware/software inventory of all components in the CUI boundary.

---

Identification and Authentication (IA)

11 tiCrypt Managed

tiCrypt handles the entire IA family. Authentication is cryptographic: users prove identity through RSA-2048 digital signature challenge-response, not by transmitting passwords. The server never stores or sees passwords. MFA integrates as an independent proof-provider (Duo, Shibboleth) that the system treats as external verification, never as a trusted insider.

Practice	Name	How tiCrypt Satisfies It
3.5.1	User, Process & Device Identification	Every user has a unique identity with an RSA-2048 key pair. Processes and VMs are identified by UUID and authenticated through digital signatures.
3.5.2	Identity Authentication	The system uses a challenge-response protocol with RSA digital signatures. The server sends a random challenge; the client signs it with their private key. No password is transmitted.
3.5.3	Multifactor Authentication	MFA integrates as an independent proof-provider (Duo, Shibboleth), verified alongside the RSA signature. It is a configurable deployment option that supplements — never replaces — the private-key authentication every session already requires. tiCrypt treats the identity provider as an independent proof-provider, not a trusted insider.
3.5.4	Replay-Resistant Authentication	The challenge-response protocol with random nonces prevents replay attacks. Each authentication session uses a unique challenge.
3.5.5	Identifier Reuse Prevention	User identifiers and UUIDs are unique and never reused. Deleted user accounts retain their identifier in the Deleted Users table.
3.5.6	Inactive Identifier Disabling	Users removed from all teams are automatically deactivated. The system's configurable session timeouts purge keys from memory.
3.5.7	Password Complexity	The system enforces configurable password strength requirements at registration and password change.
3.5.8	Password Reuse Prevention	The password only decrypts the local private key, so there is no reusable, server-side password to cycle through generations. When a user changes it, the server regenerates the IV and salt for key encryption, instantly invalidating every older copy of the key file, so a prior password can never again unlock the key.
3.5.9	Temporary Passwords	The initial account setup uses a one-time registration flow that requires immediate password creation and key file generation.
3.5.10	Cryptographic Password Protection	Passwords are never transmitted in cleartext. Authentication uses RSA digital signatures. Split credentials ensure neither client nor server alone can recover the private key.
3.5.11	Authentication Feedback Obscuring	Login interface does not reveal whether a username exists or which credential component (password vs. key file) was incorrect.

See Why tiCrypt Uses MFA But Never Trusts It for a detailed analysis of the authentication architecture.

---

Incident Response (IR)

1 Jointly Managed2 Organization

tiCrypt provides the forensic infrastructure for incident tracking. Incident response planning, reporting, and testing are organizational responsibilities.

Jointly Managed

Practice	Name	tiCrypt Provides	Your Organization Must
3.6.2	Incident Tracking & Reporting	The tamper-evident audit log and severity-based alerting supply the detection signals and forensic evidence needed to document incidents; past VM records preserve full lifecycle data for VMs that no longer exist.	Track, document, and report incidents to designated officials and authorities through its own incident-response process, including any regulatory reporting obligations.

Organization Managed

Practice	Name	What Your Organization Must Do
3.6.1	Incident-Handling Capability	Establish an incident response plan covering detection, analysis, containment, eradication, and recovery. Assign an incident response team. Define escalation procedures and communication protocols. tiCrypt's audit system provides the detection data, but your organization must define the response procedures.
3.6.3	Incident Response Testing	Test your incident response plan at least annually through tabletop exercises or simulated incidents. Document test results, lessons learned, and plan updates.

---

Maintenance (MA)

2 tiCrypt Managed4 Organization

tiCrypt secures the maintenance interface and authenticates all remote maintenance sessions. Host infrastructure maintenance, equipment sanitization, and personnel supervision are organizational responsibilities.

tiCrypt Managed

Practice	Name	How tiCrypt Satisfies It
3.7.2	Maintenance Tool Controls	tiCrypt's management interface is the sole maintenance tool. All administrative actions are authenticated, authorized, and logged. No external maintenance tools have access to CUI.
3.7.5	Nonlocal Maintenance Authentication	All remote maintenance sessions authenticate through the same RSA challenge-response protocol as standard user sessions, with MFA additionally enforced where the deployment requires it.

Organization Managed

Practice	Name	What Your Organization Must Do
3.7.1	System Maintenance	Perform timely maintenance on the host infrastructure: OS patches, firmware updates, hardware replacements. Document maintenance schedules and completion records.
3.7.3	Off-Site Equipment Sanitization	Ensure CUI is removed from equipment before it leaves the facility for maintenance. For tiCrypt hosts, encrypted drives and VM data must be sanitized before hardware decommissioning.
3.7.4	Diagnostic Media Inspection	Inspect diagnostic tools and media (USB boot drives, firmware update media) for malicious code before connecting them to tiCrypt host machines.
3.7.6	Maintenance Personnel Supervision	Supervise or escort maintenance personnel who do not have authorized access. Monitor their activities on tiCrypt host machines.

---

Media Protection (MP)

4 tiCrypt Managed5 Jointly Managed

tiCrypt provides the cryptographic dimension of media protection: all data written to any medium is encrypted with AES-256 under keys held only by data owners, so a drive, backup tape, or decommissioned disk yields only ciphertext. The platform fully provides cryptographic transport protection, removable-media control, the ownerless-media prohibition, and encrypted backup. Physical custody, access limitation, marking, transport accountability, and sanitization of the media themselves are shared with the deploying organization, which manages the physical handling around tiCrypt's ciphertext.

tiCrypt Managed

Practice	Name	How tiCrypt Satisfies It
3.8.6	Transport Encryption	The system applies AES-256 encryption to all data at rest and in transit. TLS plus Diffie-Hellman session keys protect all transport channels.
3.8.7	Removable Media Control	VMs operate in an isolated network with no USB passthrough by default. PCI/USB device access requires explicit hardware setup configuration by an administrator.
3.8.8	Ownerless Storage Prohibition	Every drive, file, and VM configuration has an explicit owner. Ownership transfer requires authenticated action. Ownership is required for all resources.
3.8.9	Backup CUI Protection	Backup data consists of encrypted chunks and encrypted drive images. Backups are inherently safe because no decryption keys are stored on the infrastructure. Any backup method (rsync, tape, snapshot) produces only ciphertext.

Jointly Managed

Practice	Name	tiCrypt Provides	Your Organization Must
3.8.1	Media Protection	All storage media contains only AES-256 encrypted data; decryption keys are never stored on the infrastructure.	Physically control and securely store the media that host the ciphertext.
3.8.2	Media Access Limitation	Access to CUI on media requires authenticated access through tiCrypt; physical possession of media yields only ciphertext.	Control physical access to the media themselves.
3.8.3	Media Sanitization	Cryptographic erasure: destroying the per-file AES-256 key renders content permanently unrecoverable; VM images reset on every boot.	Sanitize the physical media and the unencrypted metadata database per NIST SP 800-88 before disposal, release, or reuse.
3.8.4	Media Marking	tiCrypt supports configurable CUI markings and classification labels in its interfaces, aligned with 32 CFR 2002.	Apply the corresponding physical markings, distribution limitations, and handling caveats to physical media.
3.8.5	Media Transport Accountability	All data transfers are logged in the tamper-evident audit trail; transfers between Vault and VM, drive sharing, and inbox uploads are individually tracked.	Maintain custody, accountability, and handling records for physical media transported outside controlled areas.

See Carving Out a CUI Enclave on Your Existing Filesystem for additional detail on media protection over shared storage.

---

Personnel Security (PS)

2 Organization

Both PS practices are organizational responsibilities. Personnel screening and termination procedures are inherently about your people and your HR processes.

Organization Managed

Practice	Name	What Your Organization Must Do
3.9.1	Personnel Screening	Screen individuals before granting access to systems containing CUI. This includes background checks, reference verification, and any sponsor-required investigations.
3.9.2	Personnel Actions	When personnel are terminated or transferred, disable their tiCrypt account, revoke their key file, and remove them from all teams and projects. tiCrypt automatically deactivates users removed from all teams, but the organizational process to initiate removal must be defined and documented.

---

Physical and Environmental Protection (PE)

6 Organization

All six PE practices are organizational responsibilities. tiCrypt is a software platform deployed on your infrastructure. Physical security of the host machines, server rooms, and facilities is your responsibility.

Organization Managed

Practice	Name	What Your Organization Must Do
3.10.1	Physical Access Limitation	Restrict physical access to tiCrypt host machines, network equipment, and storage infrastructure to authorized personnel. Implement badge readers, biometrics, or lock-and-key controls.
3.10.2	Facility Protection & Monitoring	Protect the physical facility with perimeter controls, surveillance cameras, intrusion detection systems, and environmental controls (fire suppression, HVAC, power conditioning).
3.10.3	Visitor Escort & Monitoring	Escort visitors in areas containing tiCrypt infrastructure. Maintain visitor logs. Monitor visitor activities.
3.10.4	Physical Access Logs	Maintain logs of physical access to facilities containing tiCrypt infrastructure. Review logs regularly for unauthorized access attempts.
3.10.5	Physical Access Devices	Manage physical access devices (keys, badges, access cards). Inventory devices, change combinations periodically, and revoke access when personnel depart.
3.10.6	Alternate Work Site Safeguards	If personnel access tiCrypt from alternate work sites (home offices, satellite locations), ensure those sites have appropriate physical safeguards. tiCrypt Connect's encryption protects data in transit, but endpoint physical security is the organization's responsibility.

---

Risk Assessment (RA)

1 tiCrypt Managed1 Jointly Managed1 Organization

Tera Insights manages vulnerability remediation for all tiCrypt platform components. Vulnerability scanning is jointly managed, and risk assessments are an organizational responsibility.

tiCrypt Managed

Practice	Name	How tiCrypt Satisfies It
3.11.3	Vulnerability Remediation	Tera Insights maintains the tiCrypt software lifecycle, including vulnerability identification, patching, and release management for all platform components (backend services, frontend, VM Controller, Connect application).

Jointly Managed

Practice	Name	tiCrypt Provides	Your Organization Must
3.11.2	Vulnerability Scanning	Tera Insights performs vulnerability scanning on the tiCrypt application and its components. Security advisories are issued for vulnerabilities requiring organizational action.	Perform vulnerability scanning on the host operating systems, network infrastructure, and any non-tiCrypt software in the CUI boundary. Apply patches identified through scanning.

Organization Managed

Practice	Name	What Your Organization Must Do
3.11.1	Risk Assessment	Conduct periodic risk assessments covering the full CUI environment: tiCrypt deployment, host infrastructure, network, facilities, and organizational processes. Document risk findings and mitigation plans.

---

Security Assessment (CA)

1 tiCrypt Managed2 Jointly Managed1 Organization

tiCrypt provides continuous monitoring through the audit system. Security control assessments and plans of action are jointly managed between Tera Insights and the deploying organization.

tiCrypt Managed

Practice	Name	How tiCrypt Satisfies It
3.12.3	Continuous Monitoring	tiCrypt's audit system provides continuous monitoring of all user actions, security events, and system state changes. Severity-based alerting detects anomalies in real time. System Services monitoring tracks backend health, version, and uptime.

Jointly Managed

Practice	Name	tiCrypt Provides	Your Organization Must
3.12.1	Security Control Assessment	Tera Insights provides SSP templates covering 74 platform-managed controls, assessment evidence packages, and direct support during C3PAO assessments. tiCrypt deployments have been independently evaluated in 7+ NIST 800-171 assessments by multiple C3PAOs.	Coordinate the assessment engagement with your C3PAO. Provide evidence for the 25 organizational controls. Ensure assessment covers the full CUI boundary, not just the platform.
3.12.2	Plans of Action	Tera Insights works with your organization to develop POA&Ms for any controls not yet fully satisfied. Platform-side remediation is handled by Tera Insights.	Own the POA&M document. Track organizational remediation items. Provide milestone updates to the C3PAO on the agreed timeline.

Organization Managed

Practice	Name	What Your Organization Must Do
3.12.4	System Security Plans	Develop and maintain the System Security Plan (SSP) for your CUI environment. Tera Insights provides SSP templates that pre-document the 74 platform-managed controls, but your organization must complete the sections covering organizational controls, boundary definitions, and system descriptions. The SSP is your document and your responsibility to keep current.

---

System and Communications Protection (SC)

16 tiCrypt Managed

tiCrypt handles the entire SC family. Every SC practice is satisfied by the platform's cryptographic design, network isolation, or session management.

Practice	Name	How tiCrypt Satisfies It
3.13.1	Boundary Protection	All traffic flows through the tiCrypt backend as a single enforcement point. VMs operate on isolated networks with deny-all outbound policy. Three network segments (secure, service, data-in) separate user VMs from service VMs and data ingestion.
3.13.2	Security Architecture	tiCrypt uses a zero-knowledge architecture where the server operates on data it cannot read. Client-side encryption, RSA-based authentication, and cryptographic access control are fundamental design properties, not add-on features.
3.13.3	User/System Separation	User data and system functions are cryptographically separated. Users access CUI through encrypted VMs; the infrastructure layer never has access to plaintext data.
3.13.4	Unauthorized Transfer Prevention	The SFTP channel is write-only (local to VM). Downloads and file reads from VMs are blocked by design to prevent data exfiltration. All sanctioned transfers flow through the Vault's audited encryption layer.
3.13.5	Public Access Subnetworks	Publicly accessible components are architecturally separated from CUI processing. The tiCrypt frontend serves as the public-facing gateway; CUI processing occurs in isolated VM environments.
3.13.6	Default-Deny Network Policy	VMs start with deny-all outbound connectivity. Each outbound path (licensing servers, NFS mounts) requires explicit firewall rules created by an administrator.
3.13.7	Split Tunnel Prevention	All VM traffic routes through tiCrypt's authenticated proxy channel. No direct network path exists between VMs and external networks. Split tunneling is architecturally impossible.
3.13.8	Transmission Encryption	Transport uses double encryption: TLS on the network layer plus Diffie-Hellman session keys on the application layer. All data in transit is encrypted with FIPS-validated algorithms.
3.13.9	Network Session Termination	Sessions terminate automatically after configurable inactivity periods. Encryption keys are purged from client memory on termination.
3.13.10	Cryptographic Key Management	The key management system uses hybrid encryption: AES-256 symmetric keys for data, RSA-2048 asymmetric keys for key distribution and authentication. Keys are generated client-side and never transmitted in plaintext. Key escrow uses cryptographic shard distribution across multiple escrow groups.
3.13.11	FIPS-Validated Cryptography	All cryptographic operations use a FIPS 140-3 validated OpenSSL module. AES-256 (FIPS 197), RSA-2048 (FIPS 186-5), SHA-256 (FIPS 180-4).
3.13.12	Collaborative Computing Device Control	VM sessions are individually authenticated and isolated. Shared VMs require explicit co-owner authorization. Remote desktop and terminal sessions operate through the authenticated proxy channel.
3.13.13	Mobile Code Control	VMs operate in isolated environments with no browser-based code execution paths to external networks. The tiCrypt frontend runs in a controlled client application (tiCrypt Connect), not a general-purpose browser.
3.13.14	VoIP Control	VoIP is not supported within the tiCrypt environment. All communication occurs through authenticated, encrypted channels.
3.13.15	Session Authenticity	Every session is authenticated through the RSA challenge-response protocol and protected by TLS plus Diffie-Hellman session keys. Session tokens cannot be forged or reused.
3.13.16	CUI Protection at Rest	All CUI is encrypted at rest with AES-256. Vault files use per-chunk encryption with unique keys. VM drives use LUKS (Linux) or BitLocker (Windows) with keys held by the data owner. The infrastructure stores only ciphertext.

See Cryptographic Isolation for CUI on Shared Storage for additional detail on storage-layer isolation.

---

System and Information Integrity (SI)

7 tiCrypt Managed

tiCrypt handles the entire SI family through its immutable VM architecture, network monitoring, and automated update mechanisms.

Practice	Name	How tiCrypt Satisfies It
3.14.1	Flaw Identification & Correction	Tera Insights maintains the software lifecycle for all tiCrypt components. Security flaws are identified through internal review and external assessment, and patches are released through the standard update mechanism.
3.14.2	Malicious Code Protection	VM images are immutable and reset on every boot, eliminating persistent malware. The deny-all network policy prevents command-and-control communication. No user-installed software survives reboot.
3.14.3	Security Alert Monitoring	The system provides real-time security alerting across five severity levels. Alerts cover authentication failures, unauthorized access attempts, configuration changes, and anomalous activity patterns.
3.14.4	Malicious Code Mechanism Updates	VM images and the VM Controller are updated through the Controller Server, which serves the latest binary at boot. Image updates incorporate current security patches.
3.14.5	System & File Scanning	VM images reset on every boot, restoring a known-good state on each session. The Vault's chunk-level encryption prevents malicious file injection at the storage layer.
3.14.6	Communications Traffic Monitoring	All VM communication flows through the tiCrypt backend proxy and is logged. The deny-all network policy means any unauthorized communication attempt is both blocked and recorded.
3.14.7	Unauthorized Use Identification	The audit system detects and alerts on unauthorized access attempts, failed authentication, privilege escalation attempts, and anomalous usage patterns.

---

Summary by Responsibility Category

All 74 tiCrypt-Managed Controls

Family	Practices	Coverage
Access Control (AC)	3.1.1-3.1.15, 3.1.20	16 of 22
Audit & Accountability (AU)	3.3.1-3.3.2, 3.3.4-3.3.9	8 of 9
Configuration Management (CM)	3.4.2-3.4.9	8 of 9
Identification & Authentication (IA)	3.5.1-3.5.11	11 of 11
Maintenance (MA)	3.7.2, 3.7.5	2 of 6
Media Protection (MP)	3.8.6-3.8.9	4 of 9
Risk Assessment (RA)	3.11.3	1 of 3
Security Assessment (CA)	3.12.3	1 of 4
System & Communications Protection (SC)	3.13.1-3.13.16	16 of 16
System & Information Integrity (SI)	3.14.1-3.14.7	7 of 7

All 11 Jointly Managed Controls

Practice	Name	Family
3.1.22	Publicly Accessible Content Control	AC
3.3.3	Audit Event Review & Updates	AU
3.6.2	Incident Tracking & Reporting	IR
3.8.1	Media Protection	MP
3.8.2	Media Access Limitation	MP
3.8.3	Media Sanitization	MP
3.8.4	Media Marking	MP
3.8.5	Media Transport Accountability	MP
3.11.2	Vulnerability Scanning	RA
3.12.1	Security Control Assessment	CA
3.12.2	Plans of Action	CA

All 25 Organization-Managed Controls

Family	Practices	Count
Access Control (AC)	3.1.16-3.1.19, 3.1.21	5
Awareness & Training (AT)	3.2.1-3.2.3	3
Configuration Management (CM)	3.4.1	1
Incident Response (IR)	3.6.1, 3.6.3	2
Maintenance (MA)	3.7.1, 3.7.3-3.7.4, 3.7.6	4
Personnel Security (PS)	3.9.1-3.9.2	2
Physical & Environmental Protection (PE)	3.10.1-3.10.6	6
Risk Assessment (RA)	3.11.1	1
Security Assessment (CA)	3.12.4	1

---

Assessment Preparation

A CMMC Level 2 assessment requires evidence for all three responsibility categories. The 74 platform-managed controls produce evidence architecturally (audit exports, configuration records, cryptographic implementation details). The 25 organizational controls require institution-specific documentation: policies, procedures, training records, physical security logs, and personnel screening evidence. The 11 jointly managed controls require coordinated evidence from both the platform and the organization.

The SSP must document all 110 controls, define the CUI boundary, and describe the system architecture. Platform-managed controls can reference the architectural mechanisms described above. Organizational controls require original documentation specific to the deploying institution.

See The Shared Responsibility Gap in Cloud Research Enclaves for a comparison with managed cloud responsibility models.