NIST SP 800-171 Rev 3 Control Guide
Who implements each NIST SP 800-171 Rev 3 requirement in a tiCrypt deployment, how tiCrypt meets it, and what the university still owns. CMMC Level 2 guide
Every NIST SP 800-171 Rev 3 identifier. Answers for requirements carried from Rev 2 come from their CMMC practices; the 17 with no CMMC practice have proposed assignments. Select a row to read it in full.
| Rev 3 ID | Title | Responsibility | Requirement | How tiCrypt addresses it | University action | CMMC L2 practices | Origin | SSP control card (800-53) | Learn more |
|---|---|---|---|---|---|---|---|---|---|
Account Management | tiCrypt | Define the types of system accounts allowed and prohibited. Create, enable, modify, disable, and remove system accounts in accordance with policy, procedures, prerequisites, and criteria. Specify authorized users of the system, group and role membership, and access authorizations (i.e., privileges) for each account. Authorize access to the system based on a valid access authorization and intended system usage. Monitor the use of system accounts. Disable system accounts when the accounts have expired, have been inactive for [organization-defined time period], … (abridged) | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key. The tiCrypt Audit query "Access Attempts by Removed Users" lists each sign-in attempt made after an account was deleted, and whether the server granted or refused it.IA.L2-3.5.6The account locker deactivates accounts with no sign-in for a configurable period (90 days by default). Super-admin accounts are exempt.SC.L2-3.13.3User work runs in Secure VMs, separate from the security layer and management services; administrators never see plaintext user data. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access.IA.L2-3.5.6Set the account-inactivity period, and review Super-admin accounts, which the account locker does not deactivate. | Carried from Rev 2 | ||||
Access Enforcement | tiCrypt | Enforce approved authorizations for logical access to CUI and system resources in accordance with applicable access control policies. | AC.L2-3.1.2Permission profiles limit which actions each user can perform, with per-user overrides by administrators. Access is enforced cryptographically, so the server cannot extend access on an owner's behalf.SC.L2-3.13.3User work runs in Secure VMs, separate from the security layer and management services; administrators never see plaintext user data. | Define permission profiles and assign them to users and teams. | Carried from Rev 2 | ||||
Information Flow Enforcement | tiCrypt | Enforce approved authorizations for controlling the flow of CUI within the system and between connected systems. | AC.L2-3.1.3Within tiCrypt, CUI moves only through encrypted, audited channels (Vault transfers in encrypted chunks, managed tunnels). SFTP into the enclave is upload-only, and exports out of a project require explicit, logged authorization. In tiCrypt Audit, "File Sharing Log" lists each time a file was shared with a user or a group, with the project the file was created under, and "External SFTP Access Log" lists each check of a user's access to an external SFTP server.SC.L2-3.13.3User work runs in Secure VMs, separate from the security layer and management services; administrators never see plaintext user data. | Designate who may approve exports out of a project. Authorize where storage replication and backup jobs may copy tiCrypt's ciphertext, which is still CUI (CMMC FAQ, July 2026, question B-Q8). | Carried from Rev 2 | ||||
Separation of Duties | tiCrypt | Identify the duties of individuals requiring separation. Define system access authorizations to support separation of duties. | AC.L2-3.1.4Tiered administrative roles (sub-admin, admin, super admin, infrastructure root) separate duties, and every admin tier is cryptographically excluded from reading user data.SC.L2-3.13.3User work runs in Secure VMs, separate from the security layer and management services; administrators never see plaintext user data. | Decide which staff hold each admin tier and document the profile assignments. The tiCrypt Audit query "Privileged Accounts" lists each account whose role is above a regular user, with when the role was set and who set it. | Carried from Rev 2 | ||||
Least Privilege | tiCrypt | Allow only authorized system access for users (or processes acting on behalf of users) that is necessary to accomplish assigned organizational tasks. Authorize access to [organization-defined security functions] and [organization-defined security-relevant information]. Review the privileges assigned to roles or classes of users [organization-defined frequency] to validate the need for such privileges. Reassign or remove privileges, as necessary. | AC.L2-3.1.5Profiles grant only the actions a user needs, and data access is limited to resources whose keys were shared with the user.CM.L2-3.4.9Users can install software only where no admin privilege is needed, and those installs are discarded at shutdown; only admin-approved base-image software persists.SC.L2-3.13.3User work runs in Secure VMs, separate from the security layer and management services; administrators never see plaintext user data. | AC.L2-3.1.5Define least-privilege profiles and review privilege assignments periodically, for example with the tiCrypt Audit query "Privileged Accounts", which lists each account whose role is above a regular user.CM.L2-3.4.9Approve software added to base images. | Carried from Rev 2 | ||||
Least Privilege – Privileged Accounts | tiCrypt | Restrict privileged accounts on the system to [organization-defined personnel or roles]. Require that users (or roles) with privileged accounts use non-privileged accounts when accessing non-security functions or non-security information. | AC.L2-3.1.6Administrative functions require explicit role elevation. Administrators use separate non-privileged identities for ordinary user work.CM.L2-3.4.9Users can install software only where no admin privilege is needed, and those installs are discarded at shutdown; only admin-approved base-image software persists.SC.L2-3.13.3User work runs in Secure VMs, separate from the security layer and management services; administrators never see plaintext user data. | AC.L2-3.1.6Ensure admins use their non-privileged account for day-to-day research work.CM.L2-3.4.9Approve software added to base images. | Carried from Rev 2 | ||||
Least Privilege – Privileged Functions | tiCrypt | Prevent non-privileged users from executing privileged functions. Log the execution of privileged functions. | AC.L2-3.1.7Privileged functions are restricted to authorized admin tiers, and every privileged operation is recorded with the user's identity in the tamper-evident audit trail. The tiCrypt Audit query "Privileged Actions Audit" lists every administrative action in a period, with who performed it.CM.L2-3.4.9Users can install software only where no admin privilege is needed, and those installs are discarded at shutdown; only admin-approved base-image software persists.SC.L2-3.13.3User work runs in Secure VMs, separate from the security layer and management services; administrators never see plaintext user data. | Approve software added to base images. | Carried from Rev 2 | ||||
Unsuccessful Logon Attempts | tiCrypt | Enforce a limit of [organization-defined number] consecutive invalid logon attempts by a user during a [organization-defined time period]. Automatically lock the account or node, delay the next logon prompt, notify the system administrator, or take other action when the maximum number of unsuccessful attempts is exceeded. | Accounts lock after a configurable number of consecutive failed login attempts (default 5) and stay locked until an administrator releases them. The tiCrypt Audit queries "Failed Login Attempts" and "Failed Login Summary" list refused session requests, failed challenges and lockouts, by event and by user. | Set the lockout threshold (default 5). | Carried from Rev 2 | ||||
System Use Notification | tiCrypt | Display a system use notification message with privacy and security notices consistent with applicable CUI rules before granting access to the system. | A configurable system-use banner with privacy and security notices is displayed before login. | Provide the banner text approved by your institution. | Carried from Rev 2 | ||||
Device Lock | tiCrypt | Prevent access to the system by initiating a device lock after [organization-defined time period] of inactivity and/or requiring the user to initiate a device lock before leaving the system unattended. Retain the device lock until the user reestablishes access using established identification and authentication procedures. Conceal, via the device lock, information previously visible on the display with a publicly viewable image. | Idle sessions lock after a configurable interval (default 15 minutes), hide the display, and purge keys client-side; the user must re-authenticate. | Set the idle-lock interval (default 15 minutes). | Carried from Rev 2 | ||||
Session Termination | tiCrypt | Terminate a user session automatically after [organization-defined conditions or trigger events requiring session disconnect]. | Command sessions end automatically after inactivity, graphical sessions lock and require re-authentication, and keys are purged on logout. | Set session-termination thresholds. | Carried from Rev 2 | ||||
Remote Access | Shared | Establish usage restrictions, configuration requirements, and connection requirements for each type of allowable remote system access. Authorize each type of remote system access prior to establishing such connections. Route remote access to the system through authorized and managed access control points. Authorize the remote execution of privileged commands and remote access to security-relevant information. | AC.L2-3.1.12All remote access goes through the Connect client and the authenticated proxy; there is no direct SSH, RDP, or console access to VMs. Every session is logged.AC.L2-3.1.14The Connect client and backend proxy are the single managed entry point. Users reach the system only on port 443 and the proxy's VM tunnel ports (6000-6100 by default). Port 22 is for host administration, and the SFTP host adds port 2020 where SFTP inboxes are offered.AC.L2-3.1.15Remote privileged commands are limited to authorized admins, authenticated through the same proxy, and logged. The tiCrypt Audit query "Privileged Actions Audit" lists every administrative action, with who performed it.SC.L2-3.13.7Remote devices get only authenticated, per-port application tunnels through the proxy, not a network-level connection. There is no direct external network path to VMs. | AC.L2-3.1.15Document which remote privileged commands are authorized.SC.L2-3.13.7Enforce on your endpoints whether a device connected to tiCrypt may hold other network connections. That is an endpoint setting, not a tiCrypt setting. | Carried from Rev 2 | ||||
Wireless Access | University | Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system. Authorize each type of wireless access to the system prior to establishing such connections. Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment. Protect wireless access to the system using authentication and encryption. | University control | Carried from Rev 2 | |||||
Access Control for Mobile Devices | University | Establish usage restrictions, configuration requirements, and connection requirements for mobile devices. Authorize the connection of mobile devices to the system. Implement full-device or container-based encryption to protect the confidentiality of CUI on mobile devices. | University control | Carried from Rev 2 | |||||
Use of External Systems | Shared | Prohibit the use of external systems unless the systems are specifically authorized. Establish the following security requirements to be satisfied on external systems prior to allowing use of or access to those systems by authorized individuals: [organization-defined security requirements]. Permit authorized individuals to use external systems to access the organizational system or to process, store, or transmit CUI only after verifying that the security requirements on the external systems have been satisfied … Restrict the use of organization-controlled portable storage devices by authorized individuals on external systems. (abridged) | External systems cannot connect directly. VMs deny all outbound traffic by default, and any external endpoint (e.g., a license server) requires an explicit allowlist rule approved by a SuperAdmin. Vault files can be pushed only to external SFTP servers an administrator has approved, by the users and teams on each server's allowlist, and the tiCrypt Audit query "External SFTP Access Log" records each access check and whether it was allowed. | Define the policy for permitted external connections and exports. | Carried from Rev 2 | ||||
Publicly Accessible Content | Shared | Train authorized individuals to ensure that publicly accessible information does not contain CUI. Review the content on publicly accessible systems for CUI and remove such information, if discovered. | The platform exposes no publicly accessible content. | Designate who may post information publicly and review public postings to confirm no CUI is released. | Carried from Rev 2 | ||||
Literacy Training and Awareness | University | Provide security literacy training to system users as part of initial training for new users and [organization-defined frequency] thereafter, when required by system changes or following [organization-defined events], and on recognizing and reporting indicators of insider threat, social engineering, and social mining. Update security literacy training content [organization-defined frequency] and following [organization-defined events]. | University control | Carried from Rev 2 | |||||
Role-Based Training | University | Provide role-based security training to organizational personnel before authorizing access to the system or CUI, before performing assigned duties, and [organization-defined frequency] thereafter, and when required by system changes or following [organization-defined events]. Update role-based training content [organization-defined frequency] and following [organization-defined events]. | University control | Carried from Rev 2 | |||||
Event Logging | Shared | Specify the following event types selected for logging within the system: [organization-defined event types]. Review and update the event types selected for logging [organization-defined frequency]. | AU.L2-3.3.1Audit logging is always on and cannot be disabled or bypassed. 200+ event types are recorded (authentication, files, sharing, VMs, keys, admin actions), and records are kept for the life of the deployment by default on your own audit server.AU.L2-3.3.3tiCrypt supplies the audit data, query tools, and real-time alerting; the logged event set is defined by the product. | AU.L2-3.3.1Confirm the retention period meets your records policy (default: retained indefinitely) and back up the audit server.AU.L2-3.3.3Set a review cadence, assign reviewers, investigate alerts, and periodically confirm the logged events still meet your needs. | Carried from Rev 2 | ||||
Audit Record Content | tiCrypt | Include the following content in audit records: what type of event occurred, when the event occurred, where the event occurred, source of the event, outcome of the event, and identity of the individuals, subjects, objects, or entities associated with the event. Provide additional information for audit records as needed. | Every action is tied to an authenticated user, session, and source IP, with millisecond UTC timestamps and a hash-chain position. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Audit Record Generation | tiCrypt | Generate audit records for the selected event types and audit record content specified in 03.03.01 and 03.03.02. Retain audit records for a time period consistent with the records retention policy. | Audit logging is always on and cannot be disabled or bypassed. 200+ event types are recorded (authentication, files, sharing, VMs, keys, admin actions), and records are kept for the life of the deployment by default on your own audit server. | Confirm the retention period meets your records policy (default: retained indefinitely) and back up the audit server. | Carried from Rev 2 | ||||
Response to Audit Logging Process Failures | tiCrypt | Alert organizational personnel or roles within [organization-defined time period] in the event of an audit logging process failure. Take the following additional actions: [organization-defined additional actions]. | The logging path is fail-closed: capacity alerts fire and key issuance halts at 90% log-storage use. Real-time alerts at five severity levels flag failures such as hash-chain breaks. | Route alerts to the right staff (email, Splunk, or another SIEM). | Carried from Rev 2 | ||||
Audit Record Review, Analysis, and Reporting | tiCrypt | Review and analyze system audit records [organization-defined frequency] for indications and the potential impact of inappropriate or unusual activity. Report findings to organizational personnel or roles. Analyze and correlate audit records across different repositories to gain organization-wide situational awareness. | The separate audit system (ClickHouse) correlates events across users, resources, event types, and time ranges, and can forward alerts to Splunk, email, or other SIEMs. | Use the audit tools in your review process; set review cadence and alert routing. | Carried from Rev 2 | ||||
Audit Record Reduction and Report Generation | tiCrypt | Implement an audit record reduction and report generation capability that supports audit record review, analysis, reporting requirements, and after-the-fact investigations of incidents. Preserve the original content and time ordering of audit records. | A query builder, predefined compliance reports, direct SQL access, and Excel export support reduction and reporting without altering original records. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Time Stamps | tiCrypt | Use internal system clocks to generate time stamps for audit records. Record time stamps for audit records that meet [organization-defined granularity of time measurement] and that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp. | All components record UTC timestamps with millisecond precision. | Synchronize host clocks to an authoritative NTP source. | Carried from Rev 2 | ||||
Protection of Audit Information | tiCrypt | Protect audit information and audit logging tools from unauthorized access, modification, and deletion. Authorize access to management of audit logging functionality to only a subset of privileged users or roles. | AU.L2-3.3.8Audit records are SHA-512 hash-chained, so any change, insertion, or deletion is detectable. The backend pushes logs one way to a separate audit server with no return path.AU.L2-3.3.9Only a limited group of authorized infrastructure administrators can access audit logs, and records cannot be modified or deleted through the application. | Limit audit-server access to designated administrators. | Carried from Rev 2 | ||||
Baseline Configuration | University | Develop and maintain under configuration control, a current baseline configuration of the system. Review and update the baseline configuration of the system [organization-defined frequency] and when system components are installed or modified. | University control | Carried from Rev 2 | |||||
Configuration Settings | Shared | Establish, document, and implement the following configuration settings for the system that reflect the most restrictive mode consistent with operational requirements: [organization-defined configuration settings]. Identify, document, and approve any deviations from established configuration settings. | CM.L2-3.4.2Core security settings are architectural rather than optional. Automated configuration management reconciles components against the baseline, and system settings have full change tracking.SC.L2-3.13.7Remote devices get only authenticated, per-port application tunnels through the proxy, not a network-level connection. There is no direct external network path to VMs. | CM.L2-3.4.2Set organization-defined values and approve any deviations.SC.L2-3.13.7Enforce on your endpoints whether a device connected to tiCrypt may hold other network connections. That is an endpoint setting, not a tiCrypt setting. | Carried from Rev 2 | ||||
Configuration Change Control | tiCrypt | Define the types of changes to the system that are configuration-controlled. Review proposed configuration-controlled changes to the system, and approve or disapprove such changes with explicit consideration for security impacts. Implement and document approved configuration-controlled changes to the system. Monitor and review activities associated with configuration-controlled changes to the system. | Settings history records the previous value, new value, timestamp, and administrator. Platform releases are staged before production. | Run your change-control process (review and approve changes). | Carried from Rev 2 | ||||
Impact Analyses | tiCrypt | Analyze changes to the system to determine potential security impacts prior to change implementation. Verify that the security requirements for the system continue to be satisfied after the system changes have been implemented. | Changes to profiles, quotas, and project access go through audited Management Console controls, and Tera Insights evaluates platform changes before release. | Perform and record security impact analyses for changes in your environment. | Carried from Rev 2 | ||||
Access Restrictions for Change | tiCrypt | Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. | Configuration changes are restricted to designated admins and audited. Software and VM images are signed, and boot images reset on every boot to prevent tampering. | Designate who may make changes and run change approval. The tiCrypt Audit query "Privileged Accounts" lists who holds an administrative role. | Carried from Rev 2 | ||||
Least Functionality | Shared | Configure the system to provide only mission-essential capabilities. Prohibit or restrict use of the following functions, ports, protocols, connections, and services: [organization-defined functions, ports, protocols, connections, and services]. Review the system [organization-defined frequency] to identify unnecessary or nonsecure functions, ports, protocols, connections, and services. Disable or remove functions, ports, protocols, connections, and services that are unnecessary or nonsecure. | CM.L2-3.4.6Services are deny-by-default. Inbound traffic is limited to port 443, the proxy's VM tunnel ports (6000-6100 by default), port 22 for host administration, and port 2020 on the SFTP host where SFTP inboxes are offered. VMs boot from immutable images containing only pre-approved software, with no persistent state.CM.L2-3.4.7Images include only the OS and VM installer; extra software must be added by admins in a new image. Software can be blocked per project, and stack execution is disallowed.SC.L2-3.13.7Remote devices get only authenticated, per-port application tunnels through the proxy, not a network-level connection. There is no direct external network path to VMs. | CM.L2-3.4.7Define any per-project software blocklists.SC.L2-3.13.7Enforce on your endpoints whether a device connected to tiCrypt may hold other network connections. That is an endpoint setting, not a tiCrypt setting. | Carried from Rev 2 | ||||
Authorized Software – Allow by Exception | tiCrypt | Identify software programs authorized to execute on the system. Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system. Review and update the list of authorized software programs [organization-defined frequency]. | CM.L2-3.4.7Images include only the OS and VM installer; extra software must be added by admins in a new image. Software can be blocked per project, and stack execution is disallowed.CM.L2-3.4.8Per-project allowlists and blocklists are supported. The VM Controller governs execution, and users cannot modify boot images.CM.L2-3.4.9Users can install software only where no admin privilege is needed, and those installs are discarded at shutdown; only admin-approved base-image software persists. | CM.L2-3.4.7Define any per-project software blocklists.CM.L2-3.4.8Define per-project allow/deny lists.CM.L2-3.4.9Approve software added to base images. | Carried from Rev 2 | ||||
System Component Inventory | University | Develop and document an inventory of system components. Review and update the system component inventory [organization-defined frequency]. Update the system component inventory as part of installations, removals, and system updates. | University control | Carried from Rev 2 | |||||
Information Location | tiCrypt | Identify and document the location of CUI and the system components on which the information is processed and stored. Document changes to the system or system component location where CUI is processed and stored. | Each project's data is segregated into its own encrypted VMs, drives, and Vault storage, and tiCrypt is deployed on-premises, so CUI stays on university-controlled infrastructure. | Document CUI storage locations (storage pools, hosts) in your SSP. | None, new in Rev 3 | New in Rev 3 | |||
System and Component Configuration for High-Risk Areas | University | Issue systems or system components with the following configurations to individuals traveling to high-risk locations: [organization-defined system configurations]. Apply the following security requirements to the systems or components when the individuals return from travel: [organization-defined security requirements]. | University control | None, new in Rev 3 | New in Rev 3 | ||||
User Identification and Authentication | tiCrypt | Uniquely identify and authenticate system users, and associate that unique identification with processes acting on behalf of those users. Re-authenticate users when [organization-defined circumstances or situations requiring re-authentication]. | IA.L2-3.5.1Each user has a unique RSA-2048 identity; processes and VMs are identified by UUIDs and digital signatures.IA.L2-3.5.2Users authenticate by signing a server challenge with their private key, no password is sent. Endpoints and VMs are authenticated by key material before any connection is established. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Device Identification and Authentication | tiCrypt | Uniquely identify and authenticate [organization-defined devices or types of devices] before establishing a system connection. | Users authenticate by signing a server challenge with their private key, no password is sent. Endpoints and VMs are authenticated by key material before any connection is established. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Multi-Factor Authentication | tiCrypt | Implement multi-factor authentication for access to privileged and non-privileged accounts. | Tera Insights requires MFA for every production deployment. It runs through a provider such as Duo or Shibboleth and is layered on top of the private-key signature. The MFA assertion is signed and verified independently, and its identity must match the key holder or the session is denied. The tiCrypt Audit query "MFA Coverage by User" counts, for each user, the sign-ins completed with a multifactor token and those completed without one. | Choose and configure the MFA provider (for example Duo or Shibboleth) and keep MFA enabled. Provide MFA for host-level admin access outside tiCrypt. | Carried from Rev 2 | ||||
Replay-Resistant Authentication | tiCrypt | Implement replay-resistant authentication mechanisms for access to privileged and non-privileged accounts. | Each login challenge uses a random single-use nonce, so a captured response cannot be replayed. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Identifier Management | tiCrypt | Receive authorization from organizational personnel or roles to assign an individual, group, role, service, or device identifier. Select and assign an identifier that identifies an individual, group, role, service, or device. Prevent the reuse of identifiers for [organization-defined time period]. Manage individual identifiers by uniquely identifying each individual as [organization-defined characteristic identifying individual status]. | User identifiers and UUIDs are unique and never reused, even after deletion. | Document the period during which identifiers may not be reused. tiCrypt never reuses an identifier, so any defined period is met. | Carried from Rev 2 | ||||
Password Management | tiCrypt | Maintain a list of commonly-used, expected, or compromised passwords, and update the list [organization-defined frequency] and when organizational passwords are suspected to have been compromised. Verify that passwords are not found on that list when users create or update passwords. Transmit passwords only over cryptographically protected channels. Store passwords in a cryptographically protected form. Select a new password upon first use after account recovery. Enforce the following composition and complexity rules for passwords: [organization-defined rules]. (abridged) | IA.L2-3.5.7Configurable password-strength rules apply at registration and on change, and passwords are screened against weak or compromised lists. The password only protects the user's local private key.IA.L2-3.5.10Passwords are never sent to or stored on the server. The private key is AES-256 encrypted client-side. Tera Insights requires MFA and split credentials for every production deployment. With them enabled, the server holds the key's salt and IV and returns them only after MFA succeeds, so neither side can recover the key alone. | IA.L2-3.5.7Define password composition rules.IA.L2-3.5.10Keep MFA and split credentials enabled, and choose the MFA provider. | Carried from Rev 2 | ||||
Authentication Feedback | tiCrypt | Obscure feedback of authentication information during the authentication process. | Password entry is obscured, and login errors are generic, they do not reveal whether a username exists or which credential failed. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Authenticator Management | tiCrypt | Verify the identity of the individual, group, role, service, or device receiving the authenticator as part of the initial authenticator distribution. Establish initial authenticator content for any authenticators issued by the organization. Establish and implement administrative procedures for initial authenticator distribution; for lost, compromised, or damaged authenticators; and for revoking authenticators. Change default authenticators at first use. Change or refresh authenticators [organization-defined frequency] or when defined events occur. Protect authenticator content from unauthorized disclosure and modification. (abridged) | The authenticator is the user's client-encrypted private key, created at one-time registration and validated against a site-key chain of trust. Lockout limits guessing, and escrow supports recovery of lost keys. Tera Insights requires MFA and split credentials for every production deployment. With them enabled, a password change regenerates the server-held salt and IV, so earlier key files stop working. | Verify each person's identity before approving registration, and define procedures for lost or compromised key files. | None, new in Rev 3 | New in Rev 3 | |||
Incident Handling | University | Implement an incident-handling capability that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery. | University control | Carried from Rev 2 | |||||
Incident Monitoring, Reporting, and Response Assistance | Shared | Track and document system security incidents. Report suspected incidents to the organizational incident response capability within [organization-defined time period]. Report incident information to [organization-defined authorities]. Provide an incident response support resource that offers advice and assistance to system users on handling and reporting incidents. | Audit logs and real-time, severity-tiered alerts provide detection data and forensic evidence for investigations. | Track, document, and report incidents to designated officials and authorities, including DoD's 72-hour reporting window. | Carried from Rev 2 | ||||
Incident Response Testing | University | Test the effectiveness of the incident response capability [organization-defined frequency]. | University control | Carried from Rev 2 | |||||
Incident Response Training | University | Provide incident response training to system users consistent with assigned roles and responsibilities within [organization-defined time period] of assuming an incident response role or responsibility or acquiring system access, when required by system changes, and [organization-defined frequency] thereafter. Review and update incident response training content [organization-defined frequency] and following [organization-defined events]. | University control | None, new in Rev 3 | New in Rev 3 | ||||
Incident Response Plan | University | Develop an incident response plan that provides a roadmap for implementing the incident response capability, describes its structure and organization, defines reportable incidents, addresses the sharing of incident information, and designates responsibilities. Distribute copies of the plan to designated incident response personnel; update the plan to address system and organizational changes or problems encountered during implementation, execution, or testing; and protect the plan from unauthorized disclosure. (abridged) | University control | None, new in Rev 3 | New in Rev 3 | ||||
Maintenance Tools | Shared | Approve, control, and monitor the use of system maintenance tools. Check media with diagnostic and test programs for malicious code before it is used in the system. Prevent the removal of system maintenance equipment containing CUI by verifying that there is no CUI on the equipment, sanitizing or destroying the equipment, or retaining the equipment within the facility. | Platform maintenance runs through the management interface and SSH sessions, and all of it runs over authenticated, encrypted, audited channels. The tiCrypt Audit query "Privileged Actions Audit" lists administrative actions, service restarts included, with who performed each. | Approve and inspect any maintenance tools used on host infrastructure. | Carried from Rev 2 | ||||
Nonlocal Maintenance | tiCrypt | Approve and monitor nonlocal maintenance and diagnostic activities. Implement multi-factor authentication and replay resistance in the establishment of nonlocal maintenance and diagnostic sessions. Terminate session and network connections when nonlocal maintenance is completed. | Remote maintenance uses the same RSA challenge-response authentication plus MFA, which Tera Insights requires for every production deployment. Sessions are encrypted and closed when finished. | Pre-approve and supervise vendor remote access, and provide MFA for host-level remote access outside tiCrypt. | Carried from Rev 2 | ||||
Maintenance Personnel | University | Establish a process for maintenance personnel authorization. Maintain a list of authorized maintenance organizations or personnel. Verify that non-escorted personnel who perform maintenance on the system possess the required access authorizations. Designate organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations. | Platform maintenance runs through the management interface and SSH sessions, and all of it runs over authenticated, encrypted, audited channels. The tiCrypt Audit query "Privileged Actions Audit" lists administrative actions, service restarts included, with who performed each. | Approve and inspect any maintenance tools used on host infrastructure. | Carried from Rev 2 | ||||
Media Storage | Shared | Physically control and securely store system media that contain CUI. | File and drive contents are AES-256 encrypted before they reach any media, and decryption keys are never stored on the infrastructure. The media hold that ciphertext plus the unencrypted metadata database (file and directory names). | Physically control and securely store the media (disks, backups) that hold the ciphertext. | Carried from Rev 2 | ||||
Media Access | Shared | Restrict access to CUI on system media to authorized personnel or roles. | Reading CUI requires tiCrypt authentication and the owner's key, regardless of who can touch the media. | Control physical access to the media. | Carried from Rev 2 | ||||
Media Sanitization | Shared | Sanitize system media that contain CUI prior to disposal, release out of organizational control, or release for reuse. | Cryptographic erasure: destroying a resource's per-file or per-drive key makes the remaining ciphertext unrecoverable. The tiCrypt Audit query "File Deletions by User" counts, for each user, the files deleted directly, emptied from the trash or collected by the system, and the files whose keys and chunks the garbage collector purged. | Sanitize physical media and the unencrypted metadata database per NIST SP 800-88 before disposal or reuse, and make sure escrowed and backup key copies are destroyed. | Carried from Rev 2 | ||||
Media Marking | Shared | Mark system media that contain CUI to indicate distribution limitations, handling caveats, and applicable CUI markings. | tiCrypt's interfaces support configurable CUI markings and labels. | Apply physical markings, distribution limits, and handling caveats to media. | Carried from Rev 2 | ||||
Media Transport | Shared | Protect and control system media that contain CUI during transport outside of controlled areas. Maintain accountability of system media that contain CUI during transport outside of controlled areas. Document activities associated with the transport of system media that contain CUI. | All transfers are logged, and data in transit is encrypted end to end. | Keep custody, accountability, and handling records for physical media transported outside controlled areas. | Carried from Rev 2 | ||||
Media Use | tiCrypt | Restrict or prohibit the use of [organization-defined types of system media]. Prohibit the use of removable system media without an identifiable owner. | MP.L2-3.8.7VMs have no USB passthrough by default. Removable-media access is limited to privileged users and requires admin hardware configuration and approval.MP.L2-3.8.8Every drive, file, and VM in tiCrypt has an explicit owner, and ownership transfers require an authenticated action. | MP.L2-3.8.7Set the removable-media approval policy.MP.L2-3.8.8Enforce the owner rule for portable devices outside the platform. | Carried from Rev 2 | ||||
System Backup – Cryptographic Protection | tiCrypt | Protect the confidentiality of backup information. Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI at backup storage locations. | Backups of file and drive contents contain only ciphertext because no decryption keys are stored on the infrastructure. A backup of the platform database also holds unencrypted file and directory names. | Keep backup and replica targets inside your assessment scope: encrypted CUI is still CUI (CMMC FAQ, July 2026, question B-Q8). A cloud target must meet FedRAMP Moderate or its equivalent (CMMC FAQ, July 2026, question E-Q2). | Carried from Rev 2 | ||||
Personnel Screening | University | Screen individuals prior to authorizing access to the system. Rescreen individuals in accordance with [organization-defined conditions requiring rescreening]. | University control | Carried from Rev 2 | |||||
Personnel Termination and Transfer | University | When individual employment is terminated: disable system access within [organization-defined time period], terminate or revoke authenticators and credentials associated with the individual, and retrieve security-related system property. When individuals are reassigned or transferred: review and confirm the ongoing operational need for current logical and physical access authorizations, and modify access authorization to correspond with any changes in operational need. | University control | Carried from Rev 2 | |||||
Physical Access Authorizations | University | Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides. Issue authorization credentials for facility access. Review the facility access list [organization-defined frequency]. Remove individuals from the facility access list when access is no longer required. | University control | Carried from Rev 2 | |||||
Monitoring Physical Access | University | Monitor physical access to the facility where the system resides to detect and respond to physical security incidents. Review physical access logs [organization-defined frequency] and upon occurrence of [organization-defined events or potential indications of events]. | University control | Carried from Rev 2 | |||||
Alternate Work Site | University | Determine alternate work sites allowed for use by employees. Employ the following security requirements at alternate work sites: [organization-defined security requirements]. | University control | Carried from Rev 2 | |||||
Physical Access Control | University | Enforce physical access authorizations at entry and exit points to the facility where the system resides by verifying individual physical access authorizations before granting access and controlling ingress and egress with physical access control systems, devices, or guards. Maintain physical access audit logs for entry or exit points. Escort visitors, and control visitor activity. Secure keys, combinations, and other physical access devices. Control physical access to output devices to prevent unauthorized individuals from obtaining access to CUI. | University control | Carried from Rev 2 | |||||
Access Control for Transmission | University | Control physical access to system distribution and transmission lines within organizational facilities. | University control | None, new in Rev 3 | New in Rev 3 | ||||
Risk Assessment | University | Assess the risk (including supply chain risk) of unauthorized disclosure resulting from the processing, storage, or transmission of CUI. Update risk assessments [organization-defined frequency]. | University control | Carried from Rev 2 | |||||
Vulnerability Monitoring and Scanning | Shared | Monitor and scan the system for vulnerabilities [organization-defined frequency] and when new vulnerabilities affecting the system are identified. Remediate system vulnerabilities within [organization-defined response times]. Update system vulnerabilities to be scanned [organization-defined frequency] and when new vulnerabilities are identified and reported. | RA.L2-3.11.2Tera Insights scans tiCrypt's own components, issues advisories, and coordinates authenticated access for your scans.RA.L2-3.11.3Tera Insights identifies, patches, and releases fixes for platform components on a regular cadence, with critical fixes released out of band. | RA.L2-3.11.2Scan host operating systems, network infrastructure, and non-tiCrypt software in the CUI boundary, and remediate findings.RA.L2-3.11.3Schedule and apply platform updates; remediate host-level findings. | Carried from Rev 2 | ||||
Risk Response | Shared | Respond to findings from security assessments, monitoring, and audits. | Tera Insights remediates platform vulnerabilities on a regular cadence, with critical fixes out of band, and the audit system supplies monitoring evidence. | Respond to findings from security assessments, monitoring, and audits across the full CUI boundary. | None, new in Rev 3 | New in Rev 3 | |||
Security Assessment | Shared | Assess the security requirements for the system and its environment of operation [organization-defined frequency] to determine if the requirements have been satisfied. | Tera Insights supplies SSP templates, assessment evidence packages, and direct support during C3PAO assessments. | Coordinate the C3PAO engagement, provide evidence for university controls, and make sure the assessment covers the full CUI boundary. | Carried from Rev 2 | ||||
Plan of Action and Milestones | Shared | Develop a plan of action and milestones for the system to document the planned remediation actions to correct weaknesses or deficiencies noted during security assessments and to reduce or eliminate known system vulnerabilities. Update the existing plan of action and milestones based on the findings from security assessments, audits or reviews, and continuous monitoring activities. | Tera Insights helps draft POA&M items for platform controls, provides templated workflows, and handles platform-side remediation. | Own and track the POA&M and report milestones to the C3PAO. | Carried from Rev 2 | ||||
Continuous Monitoring | tiCrypt | Develop and implement a system-level continuous monitoring strategy that includes ongoing monitoring and security assessments. | CM.L2-3.4.9Users can install software only where no admin privilege is needed, and those installs are discarded at shutdown; only admin-approved base-image software persists.CA.L2-3.12.3The audit system continuously records user actions and security events and raises real-time alerts, providing telemetry for ongoing monitoring. | CM.L2-3.4.9Approve software added to base images.CA.L2-3.12.3Run your continuous-monitoring program using tiCrypt telemetry, including server health (CPU, memory, disk), which tiCrypt does not monitor. | Carried from Rev 2 | ||||
Information Exchange | Shared | Approve and manage the exchange of CUI between the system and other systems using interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service-level agreements, user agreements, non-disclosure agreements, or other types of agreements. Document interface characteristics, security requirements, and responsibilities for each system as part of the exchange agreements. Review and update the exchange agreements [organization-defined frequency]. | CUI enters only through logged ingress paths (Vault upload, Inboxes, SFTP), SFTP is upload-only, and data leaves only through an explicit, logged export approval, so exchange terms can be enforced technically. | Establish and manage exchange agreements (ISAs, DUAs, MOUs) and document interface responsibilities. | None, new in Rev 3 | New in Rev 3 | |||
Boundary Protection | tiCrypt | Monitor and control communications at external managed interfaces to the system and key internal managed interfaces within the system. Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. Connect to external systems only through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture. | SC.L2-3.13.1The backend is the single enforcement point. Inbound traffic is denied by default except port 443, the proxy's VM tunnel ports (6000-6100 by default), port 22 for host administration, and port 2020 on the SFTP host where SFTP inboxes are offered. VMs run on isolated networks with deny-all outbound.SC.L2-3.13.5The public-facing frontend is separated from CUI processing in isolated VM networks, and ingress services sit in a DMZ-like zone with only a one-way path to the backend. | SC.L2-3.13.1Operate the external firewall and the VLAN and switch configuration around the tiCrypt hosts and the storage that holds its ciphertext. Encryption alone does not create logical separation (CMMC FAQ, July 2026, question F-Q3).SC.L2-3.13.5Provision the VLANs and firewall rules that separate the public-facing services from the internal tiCrypt networks. | Carried from Rev 2 | ||||
Information in Shared System Resources | tiCrypt | Prevent unauthorized and unintended information transfer via shared system resources. | VMs reset to immutable images on every boot, and each service has its own database. SFTP into VMs is write-only, and transfers go through the audited Vault. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Network Communications – Deny by Default – Allow by Exception | tiCrypt | Deny network communications traffic by default, and allow network communications traffic by exception. | Inbound and outbound traffic is denied by default. Every outbound exception requires a firewall/allowlist rule created with SuperAdmin privilege. | Approve any outbound exceptions (e.g., license servers). | Carried from Rev 2 | ||||
Transmission and Storage Confidentiality | tiCrypt | Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI during transmission and while in storage. | AC.L2-3.1.13Remote sessions are double-encrypted: TLS plus a per-session Diffie-Hellman layer between client and VM, using FIPS-validated AES-256, RSA-2048, and SHA-256.MP.L2-3.8.6Data is ciphertext from the moment it is created (AES-256), so media, replicas, and backups are protected in transport without the owner's key; network transport adds TLS plus Diffie-Hellman.SC.L2-3.13.8Data in transit is double-encrypted (TLS 1.2+ plus Diffie-Hellman session keys) with FIPS-validated algorithms, and SHA-256 verifies integrity.SC.L2-3.13.16CUI is AES-256 encrypted at rest: Vault files in 8 MB chunks with per-file keys, and VM drives with LUKS or BitLocker. Metadata such as file names is not encrypted at rest. | MP.L2-3.8.6Keep encrypted media, replicas, and backups under your media-handling procedures in transport, and send them only to systems inside your assessment scope. Encrypted CUI is still CUI (CMMC FAQ, July 2026, question B-Q8).SC.L2-3.13.16Keep the storage that holds the ciphertext, and the unencrypted metadata database, inside your assessment scope: encrypted CUI is still CUI (CMMC FAQ, July 2026, question B-Q8). Do not put CUI in file or directory names. | Carried from Rev 2 | ||||
Network Disconnect | tiCrypt | Terminate the network connection associated with a communications session at the end of the session or after [organization-defined time period] of inactivity. | Tunnels close at session end and idle sessions disconnect; client keys are purged on termination. | Set the idle-disconnect interval. | Carried from Rev 2 | ||||
Cryptographic Key Establishment and Management | tiCrypt | Establish and manage cryptographic keys in the system in accordance with the following key management requirements: [organization-defined requirements for key generation, distribution, storage, access, and destruction]. | Keys are generated client-side: a random 256-bit key per file and drive, wrapped with the user's RSA-2048 public key, and an RSA-2048 key pair per user. No key is stored unwrapped on the server. Key recovery uses escrow split across independent escrow groups, three by default. | Define escrow groups (three by default) and their membership. | Carried from Rev 2 | ||||
Cryptographic Protection | tiCrypt | Implement the following types of cryptography when used to protect the confidentiality of CUI: [organization-defined types of cryptography]. | Every cryptographic operation that protects CUI runs through the OpenSSL 3.1.2 FIPS provider (CMVP #4985, FIPS 140-3) in approved mode: the key operations on the user's client and everything the VM controller does. tiCrypt implements no cryptography of its own. The backend encrypts no CUI; it verifies signatures and computes hashes with the Java runtime's libraries. Drive encryption inside VMs is performed by LUKS or BitLocker on the operating system's own validated modules, with the operating system's FIPS mode enabled. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Collaborative Computing Devices and Applications | tiCrypt | Prohibit the remote activation of collaborative computing devices and applications with the following exceptions: [organization-defined exceptions where remote activation is to be allowed]. Provide an explicit indication of use to users physically present at the devices. | Not applicable by design: collaborative computing devices (cameras, microphones) are not supported in the environment, so remote activation cannot occur. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Mobile Code | tiCrypt | Define acceptable mobile code and mobile code technologies. Authorize, monitor, and control the use of mobile code. | The frontend bundles all its dependencies and references no external code; it runs in the controlled Connect app, and software is signed. VMs have no browser-based code paths to external networks. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Session Authenticity | tiCrypt | Protect the authenticity of communications sessions. | Sessions are authenticated by RSA challenge-response over mutually authenticated channels (TLS plus Diffie-Hellman), preventing hijacking and replay. | None, provided by tiCrypt | Carried from Rev 2 | ||||
Flaw Remediation | tiCrypt | Identify, report, and correct system flaws. Install security-relevant software and firmware updates within [organization-defined time period] of the release of the updates. | Tera Insights maintains the software lifecycle, identifies flaws, and releases signed updates; VM images are rebuilt with current patches. | Apply updates on your schedule. | Carried from Rev 2 | ||||
Malicious Code Protection | tiCrypt | Implement malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code. Update malicious code protection mechanisms as new releases are available in accordance with configuration management policies and procedures. Configure malicious code protection mechanisms to perform scans of the system [organization-defined frequency] and real-time scans of files from external sources as the files are downloaded, opened, or executed, and to block, quarantine, or take other action on malicious code. (abridged) | SI.L2-3.14.2Malicious-code protection is configured in the VM image. On Linux images with ClamAV installed and clamAVEnabled = true, the VM Controller starts ClamAV at startup and runs a recursive clamscan of each drive when it is attached, writing any infected files to the controller log, which the VM's managers can read. On Windows images the anti-virus product in the image notifies the user. VM images reset at boot, which removes persistent malware, and outbound traffic is denied by default.SI.L2-3.14.4The anti-virus product and its signatures are part of the VM image. The controller server delivers the latest VM images and VM Controller at every boot, with current patches, so an updated image reaches each VM at its next start.SI.L2-3.14.5On Linux images with ClamAV enabled, the VM Controller scans each drive when it is attached and starts ClamAV's on-access client, whose coverage is set by the ClamAV configuration in the image. Boot resets restore a known-good state each session, and chunk-level encryption blocks file injection. | SI.L2-3.14.2Build an anti-virus product into your VM images and enable it (for example ClamAV on Linux, Microsoft Defender on Windows). Keep its signatures current and schedule periodic scans.SI.L2-3.14.4Keep the anti-virus product in your VM images and its signatures current.SI.L2-3.14.5Configure on-access scanning in the anti-virus product in your images and schedule periodic scans. | Carried from Rev 2 | ||||
Security Alerts, Advisories, and Directives | tiCrypt | Receive system security alerts, advisories, and directives from external organizations on an ongoing basis. Generate and disseminate internal system security alerts, advisories, and directives, as necessary. | Real-time alerts at five severity levels cover authentication failures, access attempts, and anomalies, and Tera Insights relays relevant security advisories. | Act on advisories and alerts. | Carried from Rev 2 | ||||
System Monitoring | tiCrypt | Monitor the system to detect attacks and indicators of potential attacks and unauthorized connections. Identify unauthorized use of the system. Monitor inbound and outbound communications traffic to detect unusual or unauthorized activities or conditions. | SI.L2-3.14.6All VM traffic passes through the logged backend proxy; unauthorized attempts are blocked and recorded. The audit system provides alerting (e.g., impossible-travel logins, lockouts) and forensic queries.SI.L2-3.14.7The audit system detects and alerts on unauthorized access, failed authentication, and privilege escalation. The tiCrypt Audit queries "Failed Login Attempts" and "Access Attempts by Removed Users" list failed sign-ins and sign-in attempts on deleted accounts. | SI.L2-3.14.6Run the monitoring program and route tiCrypt Audit alerts to your SOC or SIEM. Deploy your own monitoring tools on the host servers and inside VM images for the host, network and operating-system events tiCrypt does not see.SI.L2-3.14.7Investigate alerts as part of your monitoring program. | Carried from Rev 2 | ||||
Information Management and Retention | Shared | Manage and retain CUI within the system and CUI output from the system in accordance with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines, and operational requirements. | Once an operator has turned the file garbage collector on (it ships disabled and in dry-run), it destroys the key of each deleted file with its chunks after the grace period, three days by default, which leaves the content unrecoverable. Its purge records in the audit trail are the destruction record. Audit records are retained for the life of the deployment by default. | Define retention and destruction requirements from laws, contracts, and DUAs. When they are met, delete the project's files and drives, and expire and sanitize the backups. | None, new in Rev 3 | New in Rev 3 | |||
Policy and Procedures | University | Develop, document, and disseminate to organizational personnel or roles the policies and procedures needed to satisfy the security requirements for the protection of CUI. Review and update policies and procedures [organization-defined frequency]. | University control | None, new in Rev 3 | New in Rev 3 | ||||
System Security Plan | University | Develop a system security plan that defines the constituent system components; identifies the information types processed, stored, and transmitted; describes specific threats of concern; describes the operational environment and any dependencies on or connections to other systems; provides an overview of the security requirements; describes the safeguards in place or planned; and identifies individuals that fulfill system roles and responsibilities. Review and update the plan [organization-defined frequency] and protect it from unauthorized disclosure. (abridged) | University control | Carried from Rev 2 | |||||
Rules of Behavior | University | Establish rules that describe the responsibilities and expected behavior for system usage and protecting CUI. Provide rules to individuals who require access to the system. Receive a documented acknowledgement from individuals indicating that they have read, understand, and agree to abide by the rules of behavior before authorizing access to CUI and the system. Review and update the rules of behavior [organization-defined frequency]. | University control | None, new in Rev 3 | New in Rev 3 | ||||
Security Engineering Principles | tiCrypt | Apply the following systems security engineering principles to the development or modification of the system and system components: [organization-defined systems security engineering principles]. | The platform is engineered with layered security, end-to-end encryption, least privilege, and microservice isolation (zero-knowledge design). | None, provided by tiCrypt | None, new in Rev 3 | New in Rev 3 | |||
Unsupported System Components | Shared | Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer. Provide options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced. | Tera Insights maintains supported releases and patches for all tiCrypt software components. | Replace unsupported host operating systems, hypervisors, and hardware in the CUI boundary. | None, new in Rev 3 | New in Rev 3 | |||
External System Services | University | Require the providers of external system services used for the processing, storage, or transmission of CUI to comply with the following security requirements: [organization-defined security requirements]. Define and document user roles and responsibilities with regard to external system services, including shared responsibilities with external service providers. Implement processes, methods, and techniques to monitor security requirement compliance by external service providers on an ongoing basis. | University control | None, new in Rev 3 | New in Rev 3 | ||||
Supply Chain Risk Management Plan | University | Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of the system, system components, or system services. Review and update the supply chain risk management plan [organization-defined frequency]. Protect the supply chain risk management plan from unauthorized disclosure. | University control | None, new in Rev 3 | New in Rev 3 | ||||
Acquisition Strategies, Tools, and Methods | University | Develop and implement acquisition strategies, contract tools, and procurement methods to identify, protect against, and mitigate supply chain risks. | University control | None, new in Rev 3 | New in Rev 3 | ||||
Supply Chain Requirements and Processes | Shared | Establish a process for identifying and addressing weaknesses or deficiencies in the supply chain elements and processes. Enforce the following security requirements to protect against supply chain risks to the system, system components, or system services and to limit the harm or consequences from supply chain-related events: [organization-defined security requirements]. | tiCrypt software and certificates are signed and verified before deployment, development is under configuration management, and builds are security-tested in staging before release. | Establish your supply chain risk process and the security requirements you place on suppliers. | None, new in Rev 3 | New in Rev 3 | |||
This guide summarizes Tera Insights' published shared-responsibility model for tiCrypt. Each institution's System Security Plan defines its own boundary and implementation, and the final determination of compliance rests with the institution and its C3PAO. Release baseline (ticrypt.com/releases, November 13, 2026): Frontend 2.19.0 · Backend 3.16.3 · Host Controller 1.3.2 · Audit 1.11.0 · SFTP 1.5.1