tiCrypt System Security Plan
This System Security Plan documents the security controls that the tiCrypt platform provides or materially contributes to. It is a product-level reference: the badge on each control distinguishes among controls the platform satisfies on its own, controls it delivers but the organization must configure or operate, and controls it shares with the organization's own program. Controls that depend entirely on the deploying organization, such as physical protection, personnel security, and facility contingency, are intentionally excluded and identified in the scope statement. A deploying organization incorporates this shared-responsibility document by reference into its own System Security Plan, which adds the authorization boundary, system inventory, network diagrams, and organization-defined parameters.
Purpose and Scope
tiCrypt directly addresses 74 of the 110 CMMC 2.0 Level 2 practices (equivalently, the NIST SP 800-171 requirements) and jointly manages 11 more with the deploying organization — 85 controls met together — leaving the remaining 25 owned by the organization itself. tiCrypt is built on zero-knowledge infrastructure: data is encrypted with keys that never exist on the server, so a fully compromised server yields only ciphertext. Because security is enforced cryptographically rather than by trusting the infrastructure, tiCrypt satisfies a large share of the technical control families in NIST SP 800-171 Revision 3 and CMMC 2.0 Level 2 on its own.
This plan states, control by control, how the platform meets each requirement. It follows the shared-responsibility model: the controls documented here are the platform's contribution to a deployment's overall compliance posture. The deploying organization remains responsible for the organizational and physical controls listed on the right.
Provided by tiCrypt
- Access Control (AC)
- Audit and Accountability (AU)
- Identification and Authentication (IA)
- System and Communications Protection (SC)
- Configuration Management (CM, platform mechanisms)
- System and Information Integrity (SI, platform mechanisms)
- Media Protection (MP, cryptographic)
- Supply chain and backup integrity (SR / CP / SA, cryptographic)
Organizational Responsibility (Out of Scope)
- Physical and Environmental Protection (PE)
- Personnel Security (PS)
- Awareness and Training (AT)
- Facility contingency and continuity operations (CP, non-cryptographic)
- Acquisition and procurement process (SA, non-product)
The physical dimension of Media Protection (MP), along with Incident Response (IR), Risk Assessment (RA), and Security Assessment (CA), is shared: tiCrypt supplies the supporting technical capabilities documented below — encryption, tamper-evident audit, detection signals, and templated evidence — while the deploying organization owns the physical handling, program operation, and reporting.
How to read this plan. Each control card lists its NIST SP 800-171 Revision 3 requirement identifier and its CMMC 2.0 Level 2 practice, followed by the requirement and how tiCrypt implements it. CMMC 2.0 Level 2 is defined against NIST SP 800-171, so the two usually align; where a requirement exists in Revision 3 but not in CMMC 2.0 (or the reverse), the other column reads None. CMMC 2.0 Level 2 assessments are currently conducted against NIST SP 800-171 Revision 2, reflected in the CMMC practice identifiers; the Revision 3 identifiers are provided as a forward-looking reference. A control mapped to None in both columns denotes a tiCrypt capability that exceeds the CMMC 2.0 Level 2 and NIST SP 800-171 baselines. A control marked Provided · Config Required is delivered by the platform but must be enabled or operated by the deploying organization.
Access Control (AC)
Family · ACtiCrypt enforces access control cryptographically: every file, drive, and communication channel is encrypted client-side with keys that never exist on the server, so access is granted only by re-encrypting resource keys to an authorized user's RSA public key. Team, Project, Group, and Permission Profile constructs layer organizational policy on top of this cryptographic foundation, and administrators at every tier are cryptographically excluded from user data.
ITAR and export-controlled projects. tiCrypt's cryptographic model lets an organization scope who can read an ITAR-controlled research project's data to exactly the people its owner has added, with no administrative or infrastructure bypass. Every file, drive, and Secure VM is encrypted with keys that never exist on the server, and access is granted only by re-encrypting a resource's key to a specific authorized user's RSA public key. tiCrypt administrators, superadmins, and operating-system root are cryptographically excluded from project data, and each Secure VM's local operating-system credentials are randomized after boot, so there is no interactive login path into a running VM outside the cryptographic access already granted to project members. Within this model, admitting only authorized U.S. persons to a research project and excluding non-U.S. persons from membership means no non-U.S. person has a decryption path to the controlled technical data through normal use, VM access, or administrative privilege, so no deemed export occurs through those paths.
Key escrow is the one path that can exist outside project membership, and tiCrypt supports operating a research project with or without it. When escrow is enabled, a user's private key can be reconstructed only by collaboration across a minimum of three independent escrow groups, and system administrators cannot serve on the escrow team, so no single administrator can recover a key unilaterally. Because escrow members could still reach a project's data, an organization treating a research project as ITAR-controlled must ensure that any escrow-group members able to recover keys used on that project are themselves authorized U.S. persons, and must govern and log key recovery as a controlled action. For the strongest posture, an organization can instead choose not to escrow a project's accounts at all: with escrow disabled there is no recovery path, so the project members remain the only parties who can ever decrypt the data, at the cost that a lost key or forgotten password renders that data permanently unrecoverable. tiCrypt enforces the cryptographic access boundary and the multi-party structure of escrow; the deploying organization makes the export-control determination, decides project membership, chooses whether a project uses escrow, and, where escrow is used, governs escrow-group composition and key-recovery procedures. The escrow key-management mechanics are documented under SC-12.
Requirement: Define, create, enable, modify, disable, and remove system accounts in accordance with organizational policy.
How tiCrypt Implements: Each tiCrypt account is bound to an RSA-2048 key pair generated at account creation; the private key is encrypted with the user's password and never leaves the client, so an account cannot be used without possession of its key material. A user must belong to a Team to be active, which gives the deploying organization a single enforcement point for enabling and disabling accounts and for applying resource quotas. User and Permission Profiles assign each account a role with granular permissions, and administrator tiers (Sub-Admin, Admin, Super-Admin) manage accounts without any cryptographic access to user data. The deploying organization defines its Teams, Projects, and Permission Profiles and operates the account lifecycle.
Requirement: Enforce approved authorizations for logical access to information and system resources.
How tiCrypt Implements: Access enforcement in tiCrypt is cryptographic rather than purely policy based: every file and drive is encrypted with an AES-256 key, and a user can read a resource only if that key has been re-encrypted to the user's RSA public key. The server holds only ciphertext and cannot decrypt or grant access on its own; a fully compromised server yields only ciphertext. Project tags additionally gate access so that only certified active members of a project can reach tagged resources, and Permission Profiles restrict which operations each role may perform.
Requirement: Enforce discretionary access control where the owner of an object may grant or limit access to it.
How tiCrypt Implements: Resource owners exercise discretionary control directly through key management: to share a file or drive, the owner's client re-encrypts the resource's AES key to the recipient's RSA public key. The server never decrypts and cannot extend access on behalf of an owner, so the set of users able to read a resource is exactly the set the owner has cryptographically granted. Groups provide a structured mechanism for owners to share with collaborators, and access remains bounded by project certification and Permission Profiles.
Requirement: Control the flow of information within the system and between interconnected systems in accordance with approved authorizations.
How tiCrypt Implements: All information flows through managed, encrypted tunnels established by the tiCrypt Connect client; only ports 22 and 443 are permitted inbound and all other traffic is denied by default. Split tunneling is prevented, and external systems cannot connect directly to the platform. Within the platform, project tags confine data to certified active project members, and data export from a project requires explicit authorization, so information cannot leave a project boundary without an approved flow decision.
Requirement: Identify and separate the duties of individuals to reduce the risk of malevolent activity without collusion.
How tiCrypt Implements: tiCrypt provides tiered administrative roles (Sub-Admin, Admin, Super-Admin) plus infrastructure root, and all administrative tiers are cryptographically excluded from user data, structurally separating system administration from data access. User and Permission Profiles let the organization assign each individual a role with only the granular permissions that role requires, so operational duties can be divided across distinct profiles. The deploying organization defines the profile assignments that implement its specific separation-of-duties policy.
Requirement: Employ the principle of least privilege, allowing only authorized accesses necessary to accomplish assigned tasks.
How tiCrypt Implements: Every account operates under a User or Permission Profile that combines a role with granular permissions, so each user holds only the specific operations the organization assigns. Data access is further minimized cryptographically: a user can decrypt only resources whose AES keys have been re-encrypted to that user's public key, and even Super-Admins and infrastructure root cannot read user data. Project certification restricts tagged resources to certified active members. The deploying organization defines the Permission Profiles that reflect its least-privilege policy.
Requirement: Prevent non-privileged users from executing privileged functions and log the execution of privileged functions.
How tiCrypt Implements: Permission Profiles restrict privileged functions to the administrative tiers that hold the corresponding permissions, so non-privileged users cannot invoke them. tiCrypt then logs every privileged function executed by any administrative tier, and because all data access requires a key request, those requests are logged alongside administrative activity. Administrators remain cryptographically excluded from user data, so privileged functions are limited to management operations and the audit trail covers that complete set.
Requirement: Limit consecutive invalid logon attempts and take a defined action when the limit is exceeded.
How tiCrypt Implements: A tiCrypt logon requires decrypting the user's password-protected private key on the client; after a configurable number of consecutive failed decryption attempts, five by default, the account is locked and an administrator must intervene. Because authentication is challenge-response, no password is transmitted to or stored by the server. The salt and initialization vector needed to decrypt the private key are released by the server only after a successful connection, so an attacker who copies the encrypted key file offline cannot mount an unbounded offline guessing attack against it. The deploying organization sets the attempt limit and lockout action to match its policy.
Requirement: Prevent access to the system by initiating a session lock after a period of inactivity, concealing previously visible information, and retaining the lock until the user re-authenticates.
How tiCrypt Implements: Idle tiCrypt sessions lock automatically after a configurable interval, with a default of 15 minutes. On lock, the screen is obscured so previously visible information is concealed, and the session remains locked until the user re-authenticates. The deploying organization may adjust the idle interval to match its policy.
Requirement: Automatically terminate a user session after defined conditions or trigger events.
How tiCrypt Implements: tiCrypt distinguishes locking from termination. Command sessions such as terminal and SSH connections are automatically terminated after a defined period of inactivity, closing the connection rather than suspending it. Interactive graphical sessions lock at the idle threshold and require full re-authentication through the challenge-response protocol; the underlying tunnel is torn down when the session closes or the re-authentication window lapses. The deploying organization configures the inactivity thresholds that trigger termination. Terminated sessions hold no reusable credentials because no password or private key is ever stored on the server.
Requirement: Establish usage restrictions and configuration requirements for remote access, and authorize each type of remote access prior to allowing such connections.
How tiCrypt Implements: All remote access to the platform flows through a single authorized path: the tiCrypt Connect client over managed, encrypted tunnels. Every remote session is authenticated by the challenge-response protocol, in which the server issues a random nonce and the client signs it with the user's private key. When the deployment enables multi-factor authentication, a signed certificate from an external MFA provider is verified alongside the challenge before the session is authorized. External systems cannot connect directly to the platform, so no unauthorized remote access type exists.
Requirement: Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.
How tiCrypt Implements: Remote sessions run inside encrypted tunnels managed by the tiCrypt Connect client, using AES-256 (FIPS 197), RSA-2048 (FIPS 186-5), and SHA-256 (FIPS 180-4) provided by a FIPS 140-3 validated cryptographic module. Data remains encrypted end to end because all encryption and decryption occur client-side; the server never holds the keys, so a compromised transport or server exposes only ciphertext. This protects both the confidentiality and the integrity of every remote access session.
Requirement: Route remote accesses through authorized and managed network access control points.
How tiCrypt Implements: The tiCrypt Connect client is the sole managed access control point for the platform: all remote access is routed through its managed, encrypted tunnels. Only ports 22 and 443 are permitted inbound, all other traffic is denied by default, and split tunneling is prevented so a connected client cannot bridge the platform to another network. External systems cannot connect directly to the platform through any other path.
Requirement: Establish terms and conditions for the use of, and verify controls on, external systems that access the system or process organizational information.
How tiCrypt Implements: External systems cannot connect directly to the platform; the only supported access path is the tiCrypt Connect client over managed, encrypted tunnels with split tunneling prevented. Information cannot move to an external system implicitly because data export from a project requires explicit authorization, giving the organization a controlled decision point for every outbound transfer. The deploying organization defines and operates the authorization policy governing which exports are permitted.
Requirement: Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information's access restrictions, and employ mechanisms to assist users in making sharing decisions.
How tiCrypt Implements: Sharing in tiCrypt is an explicit, user-driven cryptographic act: the owner's client re-encrypts the resource's AES key to the intended recipient's RSA public key, so no share can occur accidentally or be created by the server. Groups give users a managed structure for collaborative sharing, while project tags ensure shared resources remain reachable only by certified active project members regardless of key grants. Every key request is logged, providing an auditable record of sharing activity.
Requirement: Require that privileged users employ non-privileged accounts or roles when performing nonsecurity functions.
How tiCrypt Implements: tiCrypt architecturally separates user functionality from administrative functionality. Administrators, Super-Admins, and infrastructure root accounts have no access to user data and can only configure Teams, Projects, and system settings. Administrative work is therefore performed with accounts that cannot reach user data, and access to user data requires a separate non-privileged user identity.
Requirement: Display privacy and security notices consistent with applicable CUI rules before granting access to the system.
How tiCrypt Implements: tiCrypt displays a configurable system-use notification before login, supporting CUI banners, classification markings, and terms-of-service text that users must acknowledge before gaining access. The deploying organization owns the banner content and configures the required notification text for its environment.
Requirement: Authorize the remote execution of privileged commands and remote access to security-relevant information.
How tiCrypt Implements: Privileged commands can be executed over remote access only by personnel holding administrator rights, and Permission Profiles define exactly which privileged operations each administrative tier is authorized to execute remotely. All such commands are captured in the tiCrypt audit trail, providing an accountable record of privileged remote activity. The deploying organization documents which privileged commands are authorized for remote execution.
Requirement: Control CUI posted or processed on publicly accessible systems.
How tiCrypt Implements: The tiCrypt environment exposes no publicly accessible content; all access requires authenticated, key-based login. The deploying organization designates the personnel authorized to post to public systems outside the enclave and reviews that content to ensure no CUI is released.
Audit and Accountability (AU)
Family · AUtiCrypt generates hash-chained, tamper-evident audit records for more than 110 event types, including every cryptographic key request, and streams them over a one-way push to the separately deployed tiCrypt Audit system for reduction, reporting, and forensic reconstruction. Audit data is isolated from tiCrypt administrators and users and is accessible only to a limited set of infrastructure-privileged users.
Requirement: Identify the event types the system is capable of logging and log the events selected for auditing.
How tiCrypt Implements: tiCrypt records more than 110 distinct event types. Because all data in tiCrypt is encrypted and every access requires a key request, all key requests are logged, covering file access, sharing and permission changes, group creation and modification, drive creation and attachment, VM start and stop, and VM-to-drive and VM-to-user connections. Administrative actions such as account, team, and project creation and privilege grants are logged, as are privileged-user actions. Event coverage is built into the product, is always on, and cannot be reduced or disabled; capturing these activities does not depend on any per-event configuration.
Requirement: Ensure audit records contain what type of event occurred, when and where it occurred, its source and outcome, and the identity of associated individuals or subjects.
How tiCrypt Implements: Every tiCrypt audit record contains the originating system identifier, the event timestamp, the action or event type together with the relevant event data, the success or failure outcome, the associated user when applicable, and the remote address when applicable. These fields satisfy the what, when, where, source, outcome, and identity elements of the control. Record content is fixed by the product and is applied uniformly to all logged event types.
Requirement: Generate audit records containing additional, more detailed information beyond the baseline record content.
How tiCrypt Implements: Beyond the baseline fields, tiCrypt records event-specific detail for each of its more than 110 event types, such as the objects, keys, drives, VMs, and permissions involved in an action. Key-request logging ties each data access to the specific encrypted resource requested, providing per-object detail for forensic analysis. Alerts derived from log entries never contain sensitive data, so additional detail is captured without exposing protected content in notifications.
Requirement: Alert on audit logging process failures and take defined actions in response.
How tiCrypt Implements: tiCrypt is fail-closed with respect to logging: if the logging service stops, the dependent backend services stop as well, so the system cannot continue operating without producing an audit trail. Capacity alerts fire at configurable thresholds as log storage fills, and the key manager halts key issuance at 90 percent utilization, which pauses data access until the condition is resolved. A logging failure is therefore surfaced and acted upon rather than silently ignored.
Requirement: Review and analyze audit records for indications of inappropriate or unusual activity and report findings to designated personnel.
How tiCrypt Implements: The tiCrypt Audit system provides the review and analysis capability, including audit reduction, predefined and ad hoc reports, alerts derived from log entries, and reconstruction of system state at any past point in time. Security and compliance staff can be granted full audit access without any access to the tiCrypt backend, its data, or user keys, supporting independent review. The organization must define its review frequency, assign reviewers, and configure alert thresholds and reporting procedures to operate this capability.
Requirement: Provide audit record reduction and report generation that supports on-demand analysis and reporting without altering original records.
How tiCrypt Implements: tiCrypt Audit provides audit reduction along with both predefined and ad hoc report generation for on-demand analysis. It can reconstruct the state of the system at any past point, supporting after-the-fact investigation and forensic analysis. Reduction and reporting operate on the pushed audit stream and do not alter the original record content or the time ordering of records.
Requirement: Use internal system clocks to generate audit record time stamps that map to UTC and meet a defined granularity.
How tiCrypt Implements: tiCrypt records every audit event with a UTC timestamp at millisecond precision, and tiCrypt Audit preserves the time ordering of records so timestamps support reliable sequencing and correlation during analysis. Timestamp accuracy depends on the host clock: the deploying organization synchronizes the underlying operating system clocks via NTP to an authoritative time source.
Requirement: Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
How tiCrypt Implements: Audit logs are SHA-256 hash-chained in accordance with FIPS 180-4, making them append-only and tamper-evident; any insertion, deletion, or alteration produces a detectable hash conflict. The tiCrypt Audit system is separately deployed and fed by a one-way TCP push on port 25000 with no return path, so a compromise of the audit consumer cannot reach back into the tiCrypt backend. If the logging service fails, dependent services stop rather than operate unaudited, and capacity alerts fire at configurable thresholds before storage is exhausted.
Requirement: Authorize access to management of audit logging functionality to only a defined subset of privileged users.
How tiCrypt Implements: Audit logs are accessible only to a limited set of infrastructure-privileged users with root escalation. tiCrypt administrators, Super-Admins, and ordinary users cannot access or even locate the audit logs, enforcing separation between platform administration and audit management. Security and compliance staff can be given full access to tiCrypt Audit without receiving any access to the tiCrypt backend, its data, or user keys, so audit review authority never implies platform privilege.
Requirement: Provide audit record generation capability for the defined event types on system components and generate audit records with the required content.
How tiCrypt Implements: tiCrypt generates audit records for all of its more than 110 event types across the platform, including file, group, drive, VM, administrative, and privileged-user activity, with the full record content defined under AU-3. Because every access to encrypted data requires a logged key request, record generation is inherent to the data access path and cannot be bypassed by users or administrators. Generated records are hash-chained and pushed one way to tiCrypt Audit, and if the logging service fails, dependent services stop so that activity cannot proceed unrecorded.
Requirement: Review and update the set of logged events periodically.
How tiCrypt Implements: tiCrypt audits every security-relevant action unconditionally: the set of logged event types is fixed by the product, is always on, and cannot be reduced or disabled. The deploying organization reviews that fixed event set on a defined cadence to confirm it remains complete for its operational and compliance needs, and Tera Insights incorporates any coverage gaps identified by that review into the product for all deployments.
Identification and Authentication (IA)
Family · IAtiCrypt identifies and authenticates every user and device with per-user RSA-2048 key pairs through a replay-resistant challenge-response protocol: the private key is the sole authenticator, and no one can access the system without proving possession of it. The password and any multi-factor authentication are additional protective layers around that key, not credentials in their own right; the password only decrypts and protects the private key locally, and MFA adds an independent proof on top of the key-based proof. All cryptographic operations are performed by a FIPS 140-3 validated module.
Requirement: Uniquely identify and authenticate organizational users before granting system access.
How tiCrypt Implements: Each tiCrypt user receives a unique RSA-2048 (FIPS 186-5) key pair generated at account creation, and the public key serves as the basis of the user identity. Authentication is challenge-response: the server issues a random, single-use nonce, the client signs it with the user's private key, and the server verifies the signature against the stored public key. No password is transmitted to or stored by the server. A user cannot access the system without successfully completing this cryptographic proof of identity.
Requirement: Implement multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
How tiCrypt Implements: tiCrypt integrates an external MFA provider as an independent source of proof in the authentication flow. When enabled, the signed MFA certificate is verified alongside the RSA challenge response, so a session is established only when both proofs succeed, and the deployment can require this for network access to both privileged and non-privileged tiCrypt accounts. MFA supplements, and does not replace, the private-key authentication that every session already requires. MFA enforcement is a configurable deployment option: the organization enables the external MFA provider integration and sets the accounts and conditions under which it is required. Local access to the underlying infrastructure (host operating system and root consoles) sits outside the tiCrypt application boundary; the deploying organization enforces multi-factor authentication for that local privileged access through its host and console access controls.
Requirement: Implement replay-resistant authentication mechanisms for access to accounts.
How tiCrypt Implements: Every authentication uses a random, single-use nonce issued by the server and signed by the client with the user's private key. Because each nonce is valid for exactly one authentication attempt, a captured challenge response cannot be replayed to establish a later session. This replay resistance is inherent to the protocol and applies to all accounts.
Requirement: Uniquely identify and authenticate devices before establishing a connection.
How tiCrypt Implements: Each connecting endpoint runs the tiCrypt Connect client and must present a valid cryptographic proof tied to unique key material before any session traffic is accepted, so the device is uniquely identified and authenticated before the remote connection is established. Secure VMs are likewise authenticated to the platform by key material bound to each VM when its signed image is provisioned, and the key exchange that attaches a VM to a user or drive verifies that identity on every connection. The deploying organization enrolls the endpoints authorized to run tiCrypt Connect.
Requirement: Manage system identifiers, prevent their reuse, and disable identifiers after a defined period of inactivity.
How tiCrypt Implements: Each user identity is bound to a unique RSA-2048 key pair generated at account creation, and identifiers and keys are never reused, so a retired identity cannot be reassigned. tiCrypt automatically disables accounts that remain inactive beyond a configurable period, removing their access to the system. The cryptographic binding between the identifier and the key pair ensures that each identifier maps to exactly one user for the life of the system.
Requirement: Manage system authenticators, including protecting authenticator content from unauthorized disclosure and modification.
How tiCrypt Implements: The authenticator is the user's RSA private key, which is generated at account creation and encrypted client-side with the user's password. The server never receives the password or the plaintext private key and stores no material that enables offline brute force: the salt and initialization vector are released only after a successful connection. After a configurable number of consecutive failed decryption attempts, five by default, the account locks, limiting online guessing against the authenticator.
Requirement: Enforce password composition rules and protect passwords in storage and transmission.
How tiCrypt Implements: Authentication to tiCrypt is proven solely by the user's RSA private key through digital-signature challenge-response; the password is not a network credential in its own right but a local layer that encrypts and protects that private key, and it never leaves the client. Private-key password complexity is enforced according to organization-defined composition rules, and new passwords are screened against common and compromised password lists so weak choices are rejected. Because no password is transmitted to or stored by the server, and the salt and initialization vector are released only after a successful connection, there is no server-side password material exposed to disclosure or offline attack. The password-reuse prohibition is satisfied structurally rather than by generation counting: when a user changes the password, the server regenerates the initialization vector and salt used for key encryption, instantly invalidating every older copy of the key file, so a prior password can never again unlock the key. There is no reusable, server-side password authenticator to cycle through generations, because identity is established by the private key rather than by a password, and initial or temporary access is granted only through the account activation workflow.
Requirement: For public key-based authentication, validate certificates by constructing a certification path to a trust anchor and enforce authorized access to the corresponding private key.
How tiCrypt Implements: tiCrypt authentication is PKI-based: the user's key is validated against a site-key chain of trust, and user, escrow, and software certificates all trace back to the site key as the trust anchor. Access to the private key is enforced by client-side encryption under the user's password, so only the individual who knows the password can use the key. The server verifies each challenge response against the public key associated with the validated identity.
Requirement: Obscure feedback of authentication information during the authentication process.
How tiCrypt Implements: Password entry is obscured; passwords are displayed as non-differentiated characters. On authentication failure the client presents a single generic error message that does not reveal which element of the authentication process failed, preventing an observer from learning whether the identifier, password, or MFA proof was incorrect.
Requirement: Implement mechanisms for authentication to a cryptographic module that meet applicable requirements.
How tiCrypt Implements: All tiCrypt cryptographic operations run through the OpenSSL 3.1.2 FIPS provider (CMVP certificate #4985), which is initialized and operated in its approved mode in accordance with the module's FIPS 140-3 security policy. Only tiCrypt platform processes invoke the module, and it is used exclusively in FIPS mode for every cryptographic operation on the system.
Requirement: Require users to re-authenticate when defined circumstances or situations occur.
How tiCrypt Implements: tiCrypt requires re-authentication with the private-key password after a period of inactivity. Administrators must also re-authenticate when switching between system layers, ensuring that elevated contexts are never entered on the strength of a stale session.
System and Communications Protection (SC)
Family · SCtiCrypt enforces communications protection through a three-layer architecture in which all data is encrypted end to end with client-held keys, all network access traverses a deny-all boundary admitted only by cryptographic key challenge, and user workloads execute inside logically isolated Secure VMs. Cryptographic operations use AES-256, RSA-2048, and SHA-256 through a FIPS 140-3 validated module.
Requirement: Separate user functionality, including user interface services, from system management functionality.
How tiCrypt Implements: The tiCrypt architecture separates the work layer, where user activity occurs inside Secure VMs, from the tiCrypt security layer, which provides end-to-end encryption and the management interface, and from the physical infrastructure layer. The backend consists of ten loosely coupled microservices, each with its own database and no shared state, communicating only over TCP, so management functions are structurally isolated from user workloads. User work executes exclusively inside Secure VMs and cannot reach system management services directly.
Requirement: Prevent unauthorized and unintended information transfer via shared system resources.
How tiCrypt Implements: Secure VMs boot from immutable images that reset on every boot, so no residual user information persists in a VM between sessions or is exposed to a subsequent user. Each user's work runs in a separate Secure VM on an encrypted drive whose keys are held only by the data owner and the in-VM controller. Because every microservice maintains its own database with no shared state, compromise of one service does not expose another service's data or keys.
Requirement: Protect against or limit the effects of denial-of-service events.
How tiCrypt Implements: Only ports 22 and 443 accept inbound connections, and all traffic that does not pass the cryptographic key challenge is dropped at the deny-all firewall before reaching interior services. Secure VMs deny all inbound and outbound traffic by default. This sharply limits the surface available to a flooding or protocol-abuse attack; network-layer denial-of-service defense at the perimeter remains a shared responsibility with the deploying organization and its network provider.
Requirement: Monitor and control communications at the external boundary and key internal boundaries of the system.
How tiCrypt Implements: The external boundary permits inbound traffic only on ports 22 and 443 and denies everything else by default. All user access flows through the tiCrypt Connect client, which establishes managed, encrypted tunnels terminating at a deny-all firewall; only traffic certified by the cryptographic key challenge is admitted. Internally, Secure VMs are logically isolated from other VMs and from the network, accept no direct inbound connections, and expose only a controller-managed tunnel that does not run SSH.
Requirement: Limit the number of external network connections to the system.
How tiCrypt Implements: The system exposes exactly two inbound ports, 22 and 443, and a single access path: the tiCrypt Connect client tunnel terminating at the deny-all firewall. Secure VMs present no external access points of their own; their only open port is a controller-managed tunnel, and all VM traffic is mediated by the encrypted proxy. This design reduces external connectivity to one managed, cryptographically gated channel.
Requirement: Deny network communications traffic by default and allow it by exception.
How tiCrypt Implements: Deny by default is enforced at every layer. Inbound, all ports except 22 and 443 are denied, and the tunnel terminates at a deny-all firewall that admits only traffic certified by the cryptographic key challenge. Outbound, Secure VMs deny all traffic by default; the only exceptions are explicit licensing allowlist entries, and creating such an entry requires the highest privilege in the system.
Requirement: Prevent split tunneling for remote devices connecting to the system.
How tiCrypt Implements: Remote access is possible only through the software-defined network established by the tiCrypt Connect client. Every packet stream entering the boundary must be certified by the cryptographic key challenge; non-certified streams are rejected outright. A remote device therefore cannot route traffic into the system outside the managed tunnel, which structurally prevents split tunneling.
Requirement: Protect the confidentiality and integrity of transmitted information.
How tiCrypt Implements: All information in transit is protected end to end between the client and the destination using keys held by the client, not by intermediary infrastructure. VM session traffic is mediated by an end-to-end encrypted proxy over mutually authenticated WebSocket connections with Diffie-Hellman key negotiation; after the handshake, no component between the user and the VM, including the proxy itself, can read session traffic. Integrity is verified with SHA-256 hashing.
Requirement: Implement cryptographic mechanisms to prevent unauthorized disclosure of and detect changes to information during transmission.
How tiCrypt Implements: Transmission protection uses AES-256 (FIPS 197) for data encryption, RSA-2048 (FIPS 186-5) for key wrapping and authentication, and SHA-256 (FIPS 180-4) for integrity, all through a FIPS 140-3 validated cryptographic module. Session keys for VM traffic are negotiated per connection with Diffie-Hellman exchange over mutually authenticated channels, so disclosure or modification in transit is cryptographically prevented and detectable.
Requirement: Terminate the network connection associated with a communications session at the end of the session or after a defined period of inactivity.
How tiCrypt Implements: The encrypted tunnel is torn down when the session closes, ending the network connection rather than leaving it open. After a configurable idle interval, 15 minutes by default, the session locks and requires re-authentication, and the network connection is terminated if the session is not resumed. The deploying organization sets the idle interval to match its policy.
Requirement: Establish and manage cryptographic keys when cryptography is employed within the system.
How tiCrypt Implements: RSA key pairs are generated on the client side, so private keys never originate on or transit through the server. A site-key chain of trust signs certificates, anchoring key authenticity. Key recovery uses multi-party escrow that requires a minimum of three independent escrow groups, so no single holder can recover a key alone; system administrators cannot be members of the escrow team, so key recovery cannot be performed unilaterally by the people who operate the infrastructure. The organization defines the escrow group membership during deployment.
Requirement: Implement cryptography in accordance with applicable laws and standards, including FIPS-validated cryptography for protecting CUI.
How tiCrypt Implements: tiCrypt does not implement its own cryptography. All cryptographic operations are performed exclusively by the OpenSSL 3.1.2 FIPS provider (CMVP certificate #4985) with FIPS mode enabled on the virtual machine operating system, for both standalone Secure VMs and the Slurm HPC integration. The platform uses AES-256 (FIPS 197) for data, RSA-2048 for authentication and digital signatures per FIPS 186-5, and SHA-256 (FIPS 180-4) for hashing, with all RSA key-encapsulation and key-transport operations carried out inside the validated module in its approved mode. Because every operation runs in the validated module under FIPS mode, the FIPS-validated cryptography requirement for protecting controlled unclassified information is satisfied.
Requirement: Prohibit remote activation of collaborative computing devices and indicate use to users present at the device.
How tiCrypt Implements: Collaborative computing devices such as shared cameras and microphones are not supported by the tiCrypt platform. Because the capability does not exist, remote activation is not possible, and the control is satisfied by exclusion.
Requirement: Protect the authenticity of communications sessions.
How tiCrypt Implements: Session authenticity is ensured by a secure channel established over the managed tunnel using public-key cryptography, with RSA-2048 authentication binding the session to the client-held key. VM connections use mutually authenticated WebSocket channels with per-session Diffie-Hellman key negotiation, so neither endpoint can be impersonated and a session cannot be hijacked or replayed by an intermediary.
Requirement: Protect the confidentiality of information at rest.
How tiCrypt Implements: Vault file content is split into 8 MB chunks, each independently encrypted with AES-256 (AES-CBC) using keys held only by the data owner, so file content at rest is protected as ciphertext and no server-side component holds the keys to decrypt it. VM storage uses encrypted drives, LUKS on Linux or BitLocker on Windows, with AES-256. File and directory metadata, including names, is stored separately in the platform database and is not encrypted at rest, so deploying organizations must avoid placing CUI in file or directory names. The at-rest cipher provides confidentiality; integrity of stored content relies on the surrounding platform controls rather than an authenticated-encryption mode.
Requirement: Maintain a separate execution domain for each executing process.
How tiCrypt Implements: User work executes inside separate Secure VMs on encrypted drives, giving each workload its own hardware-virtualized execution domain that is logically isolated from other VMs and from the network. Within the VM, the kernel disallows stack execution, blocking a common class of code-injection attacks. Backend microservices are similarly separated, each with its own database and no shared state.
Requirement: Control and monitor the use of mobile code.
How tiCrypt Implements: The tiCrypt frontend bundles all of its dependencies and references no external JavaScript, CSS, or HTML, which eliminates unreviewed mobile code from the client. All software is distributed as digitally signed packages that are reviewed through the tiCrypt secure development lifecycle, so mobile code use is controlled end to end.
Requirement: Control and monitor the use of Voice over Internet Protocol technologies.
How tiCrypt Implements: Voice over Internet Protocol is not used within the tiCrypt system. No VoIP services are provided, configured, or reachable inside the environment, so this control does not apply.
Configuration Management (CM)
Family · CMtiCrypt provides the technical mechanisms for this family, including least functionality, controlled software execution inside Secure VMs, and information location controls, while the deploying organization owns and operates the broader change-management program, including change approval, testing, and documentation processes.
Requirement: Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.
How tiCrypt Implements: Changes to tiCrypt-level configuration, including Teams, Projects, and permissions, are restricted to designated administrators, and security-layer changes are separated from the data they protect. Software components are distributed as digitally signed packages tied to a site-key chain of trust, so unsigned or tampered components are not accepted. Secure VMs boot from immutable, signed images that reset on every boot; changes to the VM system disk are discarded at shutdown, so no unauthorized persistent modification survives. The organization assigns administrator roles and operates the change approval and documentation process around these mechanisms.
Requirement: Configure the system to provide only essential capabilities and restrict the use of nonessential functions, ports, protocols, and services.
How tiCrypt Implements: The platform is architected deny-by-default: only essential functions, ports, protocols, and services are enabled, with inbound access limited to ports 22 and 443. Secure VM images contain only pre-approved software, and data cannot leave the enclave without explicit authorization. This restricts each project environment to the minimum functionality required for its research workload.
Requirement: Prevent program execution in accordance with defined policies, rules of behavior, and access agreements regarding software program usage.
How tiCrypt Implements: Software execution inside Secure VMs is controlled per project: software can be blacklisted to prevent it from being brought into a VM or whitelisted to explicitly permit it, matching each project's authorization rules. Before an image is created for a project, all software is expressly authorized and no other software may be added to the image. The kernel additionally disallows stack execution, blocking a common malicious-code execution path.
Requirement: Identify software programs not authorized to execute and employ a deny-by-exception policy to prohibit their execution.
How tiCrypt Implements: tiCrypt supports per-project software blacklisting, preventing identified software from being brought into a Secure VM. Because project needs vary, there is no single global rule; the organization defines which software is prohibited for each project and configures the corresponding blacklist. Blacklisted software cannot be introduced into the project's Secure VMs.
Requirement: Identify software programs authorized to execute and employ an allow-by-exception policy to permit execution of only authorized software.
How tiCrypt Implements: tiCrypt supports per-project software whitelisting, under which only explicitly permitted software may be used inside a project's Secure VMs. Secure VM images include only pre-approved software: images are built and certified outside the enclave, signed, and then inserted for a project; before an image is created, all software is expressly authorized, and no other software may be added. The organization defines the authorized software list for each project and configures the whitelist accordingly.
Requirement: Establish and enforce policies governing the installation of software by users and monitor compliance.
How tiCrypt Implements: Users may install software inside a Secure VM only when the installation does not require host or administrator privilege and the project imposes no constraint on that software. Project-level blacklists and whitelists enforce the organization's installation policy, and any software installed on the VM system disk is discarded at shutdown because Secure VMs reset to their signed image on every boot. Where a project requires additional software, custom images can be built and certified to meet the project's requirements. The organization defines the per-project installation policy that these mechanisms enforce.
Requirement: Identify and document the location of information and the specific system components on which the information is processed and stored.
How tiCrypt Implements: Each project's data is segregated into project-specific Secure VMs and encrypted drives, so the location of a project's information is defined by its assigned components. Only users with explicitly assigned permissions and valid certifications can reach a project's data, and data cannot leave the enclave without explicit authorization. This structural segregation makes the processing and storage location of each project's information identifiable and enforced by the platform.
Requirement: Establish and enforce security configuration settings for system components.
How tiCrypt Implements: tiCrypt enforces security configuration settings through centrally managed, automated configuration management, which continuously reconciles each component against the approved baseline and prevents unauthorized drift. The deploying organization defines the setting values appropriate for its environment and documents them as its configuration baseline.
Requirement: Track, review, approve, and log changes to the system.
How tiCrypt Implements: tiCrypt logs every configuration change in the tamper-evident audit trail, and Tera Insights validates platform releases in a separate staging environment before they are promoted to production. The deploying organization operates the change-control process itself, including tracking, review, approval authority, scheduling, and change records.
Requirement: Analyze the security impact of changes prior to implementation.
How tiCrypt Implements: Changes to the platform and its configuration are evaluated for security impact before deployment, supported by the platform's change tooling and the separate test environment used for validation. The deploying organization performs and records the security impact analysis as part of its own change-control process.
System and Information Integrity (SI)
Family · SItiCrypt partially addresses the SI family through anti-virus scanning integration on encrypted drives, digitally signed software and VM images validated against a site-key chain of trust, SHA-256 hash-chained audit logs, sanitized error handling, and reliance on operating-system memory protections.
Requirement: Identify, report, and correct system flaws in a timely manner.
How tiCrypt Implements: Tera Insights tracks security flaws in the tiCrypt platform and issues corrections as digitally signed updates tied to the site-key chain of trust. Secure VM images are rebuilt from updated, signed base images so that fixes take effect on the next boot. The deploying organization applies platform updates and rebuilds images on its own remediation cadence.
Requirement: Implement malicious code protection at system entry and exit points to detect and eradicate malicious code.
How tiCrypt Implements: Within Secure VMs, tiCrypt scans files with the organization's anti-virus software when they are imported into encrypted drives and again on every read and write. Secure VMs boot from immutable images that reset at each boot, so persistent malware and rootkits cannot survive a reboot. The organization supplies and manages the specific anti-virus product and schedules periodic full scans of the persistent encrypted drives on the cadence its policy requires; tiCrypt provides the scanning integration, the entry-and-exit-point scanning, and the reset-on-boot guarantee.
Requirement: Monitor the system to detect attacks, indicators of potential attacks, and unauthorized connections.
How tiCrypt Implements: tiCrypt Audit ingests the platform's tamper-evident event stream and supports severity-based alerting and ad hoc forensic queries over more than 110 event types, giving monitoring staff near real-time visibility into authentication, access, and administrative activity. The deploying organization operates the monitoring program, defines the alert conditions it acts on, and integrates the audit stream with its own security monitoring.
Requirement: Employ integrity verification tools to detect unauthorized changes to software, firmware, and information.
How tiCrypt Implements: tiCrypt components are distributed as digitally signed packages tied to a site-key chain of trust and are validated before deployment. VM images are signed and certified, and every VM boots from the original signed image. Audit logs are SHA-256 hash-chained in an append-only structure, so any modification to recorded log entries is detectable.
Requirement: Perform integrity checks of software, firmware, and information at startup or at defined transitional states.
How tiCrypt Implements: The platform enforces software integrity at each transitional state: components are validated against their digital signatures before deployment, and because every Secure VM boots from its original signed and certified image, any unauthorized modification made during a prior session is discarded at the next boot rather than persisted.
Requirement: Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited, and reveal them only to authorized personnel.
How tiCrypt Implements: tiCrypt displays error messages only to authorized personnel. Error messages and error logs are written to avoid revealing sensitive information; for example, account numbers, identifiers, and medical data are not placed in error logs.
Requirement: Implement safeguards to protect system memory from unauthorized code execution.
How tiCrypt Implements: The platform relies on operating-system memory protections, such as disallowing execution of code from the stack, to prevent unauthorized code execution in memory. These protections apply to the environments in which tiCrypt components run.
Requirement: Monitor system security alerts and advisories and take action in response.
How tiCrypt Implements: Tera Insights monitors security alerts and advisories relevant to the platform and communicates the applicable ones to operations staff and administrators. The deploying organization acts on those advisories and issues any internal security directives required by its policy.
Media Protection (MP)
Family · MPtiCrypt provides the cryptographic dimension of media protection: all data written to storage media is encrypted with AES-256 under keys held only by the data owner, so possession of any physical medium yields only ciphertext. Physical media handling, labeling, marking, and custody remain the responsibility of the deploying organization.
Requirement: Physically control and securely store system media containing sensitive information.
How tiCrypt Implements: tiCrypt provides the cryptographic component of secure media storage: all data at rest is encrypted with AES-256 (FIPS 197) before it reaches any storage medium, using keys held only by the data owner on the client side. Encrypted drives use LUKS on Linux or BitLocker on Windows with AES-256, and Vault files are split into 8 MB chunks that are each independently encrypted. The infrastructure never holds plaintext or encryption keys, so physical possession of a storage medium yields only ciphertext. Physical control and custody of the media themselves are handled by the deploying organization.
Requirement: Implement cryptographic mechanisms to protect the confidentiality of information stored on media during transport outside controlled areas.
How tiCrypt Implements: Because tiCrypt encrypts all data end to end with AES-256 before it reaches storage, information on any medium is already ciphertext at the moment the medium is created. Encrypted media and backups can therefore be transported or stored on untrusted storage without exposing the underlying data. Decryption requires the data owner's RSA private key, which never leaves the owner's control, so interception or loss of media in transit does not compromise confidentiality.
Requirement: Sanitize system media before disposal, release, or reuse so that information cannot be recovered.
How tiCrypt Implements: tiCrypt implements sanitization of file content through cryptographic erasure. Each resource is encrypted under its own unique AES-256 key, and destroying that key renders the corresponding ciphertext permanently unrecoverable and computationally indistinguishable from random noise, across all copies including backups, with no disk-level overwriting required. Because the infrastructure never holds keys or plaintext, no residual recoverable content remains after key destruction; unencrypted file and directory metadata in the platform database is sanitized through the organization's media procedures.
Requirement: Limit access to CUI on system media to authorized users.
How tiCrypt Implements: Access to data on media managed by tiCrypt requires the data owner's private key, obtained through cryptographic key sharing or signature authentication, so the infrastructure hosting the media cannot read its content. The deploying organization controls physical access to the media itself.
Requirement: Mark media containing CUI with applicable markings, distribution limitations, and handling caveats.
How tiCrypt Implements: tiCrypt supports configurable CUI markings and classification labels in its interfaces, aligned with 32 CFR 2002 and the NARA CUI registry. The deploying organization configures the markings it requires and applies the corresponding physical markings to media.
Requirement: Protect and control media containing CUI during transport outside controlled areas.
How tiCrypt Implements: All data transported by tiCrypt is encrypted end to end under keys the data owner controls, so media in transit contains only ciphertext that is unreadable without the owner's private key. The deploying organization maintains custody, accountability, and handling records for physical media transport.
Requirement: Control the use of removable media on system components.
How tiCrypt Implements: Removable media use is limited to privileged users and requires approval; non-privileged users cannot use removable media within the system. The deploying organization defines and enforces the removable-media policy that governs those approvals.
Requirement: Prohibit the use of portable storage devices that have no identifiable owner.
How tiCrypt Implements: All media in tiCrypt is cryptographically bound to a specific user, so portable storage without an identifiable owner cannot be used with the system. The deploying organization enforces the prohibition operationally for devices handled outside the platform.
Supply Chain and Backup Integrity (SR / CP / SA)
Family · SR · CP · SAtiCrypt is distributed as digitally signed software whose components trace to a site-key chain of trust, and all data it manages is encrypted at all times, so backups contain only ciphertext. Tera Insights develops, tests, and releases tiCrypt under configuration management with pre-release security evaluation.
Requirement: Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of backup information.
How tiCrypt Implements: All tiCrypt data is always encrypted, so any backup contains only ciphertext. The same cryptographic mechanisms that protect live data protect the confidentiality of backups, and decryption requires the data owner's RSA private key, which is never present in the backup. As a result, Vault chunks can be replicated to untrusted or cloud storage without compliance risk.
Requirement: Develop and implement anti-counterfeit measures that detect and prevent counterfeit components from entering the system.
How tiCrypt Implements: tiCrypt software is distributed as digitally signed packages. VM images and user, escrow, and software certificates trace to a site-key chain of trust. Signatures are verified before deployment, so tampered or counterfeit components are detectable and rejected before they enter the system.
Requirement: Apply systems security engineering principles to the specification, design, development, and implementation of the system.
How tiCrypt Implements: tiCrypt is built on systems security engineering principles. A three-layer architecture separates the physical infrastructure, the tiCrypt security layer, and the work layer inside Secure VMs. Security is enforced cryptographically rather than by trusting the infrastructure, so a compromised server or a privileged insider sees only ciphertext. End-to-end encryption, least privilege, and defense in depth are foundational design properties rather than add-on features, and the backend's loosely coupled microservices isolate management functions from user workloads. These principles are applied throughout the development lifecycle documented under SA-10 and SA-11 and are detailed in the tiCrypt Security Architecture whitepaper.
Requirement: Require the system developer to perform configuration management during development, track security flaws and their resolution, and control the integrity of changes.
How tiCrypt Implements: Tera Insights develops tiCrypt under configuration management and tracks security flaws and their resolution through release. Only builds that complete this process are digitally signed for distribution, so the integrity of each released component is verifiable against the signing chain. Releases are validated in a staging instance before production deployment.
Requirement: Require the system developer to perform security testing and evaluation and to correct identified flaws.
How tiCrypt Implements: Tera Insights performs security testing and evaluation of tiCrypt before releasing signed builds. Identified flaws are tracked to resolution as part of the development process. Each release is validated in a staging instance before it is deployed to production.
Incident Response (IR)
Family · IRtiCrypt does not run the organization's incident-response program, but its tamper-evident audit trail and security alerting supply the detection, tracking, and evidence that the program depends on.
Requirement: Track, document, and report incidents to designated officials and authorities.
How tiCrypt Implements: The tiCrypt audit system tracks more than 110 event types at millisecond precision with tamper-evident integrity, and security alerts for role changes, geolocation anomalies, and potential attacks give responders the detection signals and evidence needed to document incidents. The deploying organization tracks and reports incidents through its own incident-response process.
Maintenance (MA)
Family · MAPlatform maintenance is performed through the same controlled, authenticated, and encrypted administrative channels as all other privileged access; the deploying organization operates its maintenance program on top of those controls.
Requirement: Control and monitor the tools used to conduct system maintenance.
How tiCrypt Implements: Platform maintenance is carried out through the tiCrypt administrative console and audited SSH sessions over the same authenticated, encrypted channels as all privileged access, and maintenance software is distributed as digitally signed packages validated against the site-key chain of trust. Every maintenance action is recorded in the tamper-evident audit trail. The deploying organization approves which maintenance tools are permitted, inspects them before use, and supervises their use.
Requirement: Approve, monitor, and protect nonlocal maintenance and diagnostic activities.
How tiCrypt Implements: Nonlocal maintenance runs exclusively over encrypted channels and is authenticated by the same cryptographic challenge-response protocol as all administrative access, with multi-factor authentication additionally enforced where the deployment requires it. Vendor maintenance access requires pre-approval, with organizational personnel present through screen sharing for the duration of the session. The deploying organization authorizes and supervises all nonlocal maintenance activity.
Risk Assessment (RA)
Family · RAtiCrypt supports vulnerability management by enabling authenticated scanning access and delivering signed remediation, while the deploying organization owns the risk-assessment and scanning program.
Requirement: Scan for vulnerabilities periodically and when new vulnerabilities affecting the system are identified.
How tiCrypt Implements: The deploying organization performs vulnerability scanning using its own scanning tools. Tera Insights coordinates scan scheduling and provides privileged, authenticated access so scans achieve comprehensive coverage of the platform.
Requirement: Remediate vulnerabilities in accordance with risk assessments.
How tiCrypt Implements: Tera Insights remediates platform vulnerabilities on a regular patch cadence, with critical fixes released out of band, and the modular architecture enables targeted patching of affected components. The deploying organization schedules and applies remediation for its deployment based on its own risk assessments.
Security Assessment (CA)
Family · CAtiCrypt supplies the audit evidence, templated documentation, and continuous-monitoring telemetry that the deploying organization uses to assess, authorize, and continuously monitor the system.
Requirement: Periodically assess the security controls to determine whether they are effective in their application.
How tiCrypt Implements: Security control assessments are performed by the organization's audit function and by independent assessors. Tera Insights supports these assessments by providing audit data, templated documentation, and direct assistance during the assessment.
Requirement: Develop and implement plans of action to correct deficiencies and reduce or eliminate vulnerabilities.
How tiCrypt Implements: The deploying organization develops and maintains plans of action and milestones for identified deficiencies. Tera Insights assists with remediation planning and tracking through templated workflows that feed those plans.
Requirement: Monitor security controls on an ongoing basis to ensure their continued effectiveness.
How tiCrypt Implements: The tiCrypt audit engine supplies the continuous-monitoring telemetry, tracking more than 110 event types in real time with tamper-evident integrity. The deploying organization operates the continuous-monitoring program and defines the reviews, metrics, and reporting built on that telemetry, including the ongoing assessment of control effectiveness.
Customer Responsibility Matrix
The table below assigns each of the 110 CMMC 2.0 Level 2 practices a disposition: practices marked Provided or Config Required count as directly addressed by tiCrypt (74), Shared practices are jointly managed (11), and the remainder are owned by the deploying organization (25). Two System and Communications Protection practices — VoIP (3.13.14) and collaborative computing devices (3.13.12) — are satisfied by exclusion because the underlying capability does not exist in the platform, and are counted as directly addressed.
| Family | Total | tiCrypt-addressed | Shared | Org-owned |
|---|---|---|---|---|
| Access Control (AC) | 22 | 16 | 1 | 5 |
| Awareness & Training (AT) | 3 | 0 | 0 | 3 |
| Audit & Accountability (AU) | 9 | 8 | 1 | 0 |
| Configuration Management (CM) | 9 | 8 | 0 | 1 |
| Identification & Authentication (IA) | 11 | 11 | 0 | 0 |
| Incident Response (IR) | 3 | 0 | 1 | 2 |
| Maintenance (MA) | 6 | 2 | 0 | 4 |
| Media Protection (MP) | 9 | 4 | 5 | 0 |
| Personnel Security (PS) | 2 | 0 | 0 | 2 |
| Physical & Environmental Protection (PE) | 6 | 0 | 0 | 6 |
| Risk Assessment (RA) | 3 | 1 | 1 | 1 |
| Security Assessment (CA) | 4 | 1 | 2 | 1 |
| System & Communications Protection (SC) | 16 | 16 | 0 | 0 |
| System & Information Integrity (SI) | 7 | 7 | 0 | 0 |
| Total | 110 | 74 | 11 | 25 |
The 11 jointly managed practices: 3.1.22 Publicly Accessible Content (AC); 3.3.3 Audit Event Review & Updates (AU); 3.6.2 Incident Tracking & Reporting (IR); 3.8.1 Media Protection, 3.8.2 Media Access, 3.8.3 Media Sanitization, 3.8.4 Media Marking, 3.8.5 Media Transport Accountability (MP); 3.11.2 Vulnerability Scanning (RA); 3.12.1 Security Control Assessment, 3.12.2 Plans of Action (CA).
The 25 organization-owned practices: wireless, mobile-device, and external-portable-storage controls 3.1.16–3.1.19, 3.1.21 (AC); all awareness and training 3.2.1–3.2.3 (AT); baseline configuration and inventory 3.4.1 (CM); incident-handling capability and testing 3.6.1, 3.6.3 (IR); host maintenance, off-site sanitization, diagnostic-media inspection, and maintenance-personnel supervision 3.7.1, 3.7.3, 3.7.4, 3.7.6 (MA); personnel screening and actions 3.9.1–3.9.2 (PS); all physical and environmental protection 3.10.1–3.10.6 (PE); organizational risk assessment 3.11.1 (RA); and the System Security Plan itself 3.12.4 (CA).
Organization-Defined Parameters
tiCrypt's security guarantees are architectural and non-optional: auditing is always on and cannot be disabled, encryption is always applied, and administrators are cryptographically excluded from user data. The parameters below are the operational settings a deploying organization tunes to its policy; none of them can weaken those guarantees.
| Parameter | tiCrypt default | Set by |
|---|---|---|
| Failed private-key decryption attempts before lockout | 5 | Organization |
| Idle session-lock / screen-lock interval | 15 minutes | Organization |
| Command and remote session termination timeout | Organization-defined | Organization |
| System-use notification (banner) text | Organization-defined | Organization |
| Private-key password composition rules | Enforced; values organization-defined | Organization |
| Account inactivity disable period | Organization-defined | Organization |
| Audit review cadence and assigned reviewers | Organization-defined | Organization |
| Audit alert thresholds and notification routing | Organization-defined | Organization |
| Log-storage capacity alert; key issuance halts | 90% utilization | Organization |
| Audit record retention period | Retained indefinitely by default | Organization |
| Escrow group count (minimum three) and membership | ≥ 3 groups | Organization |
| Multi-factor authentication enablement and scope | Off until enabled | Organization |
| Removable-media approval policy | Privileged users only | Organization |
Summary
tiCrypt implements the technical core of a NIST SP 800-171 Revision 3 and CMMC 2.0 Level 2 compliant environment: cryptographic access control, tamper-evident auditing, public-key identification and authentication, boundary and communications protection, and protection of information at rest and in transit. Because every one of these controls is enforced with keys the infrastructure never holds, none can be silently bypassed by a compromised server or a privileged insider. Combined with the organizational controls that remain the deploying organization's responsibility, the platform supplies the technical foundation for an authorized, compliant secure-research enclave.
For the cryptographic architecture behind these controls, see the tiCrypt Security Architecture whitepaper.