Getting Data Into the Enclave: tiCrypt's Ingress Methods Explained
tiCrypt's security model is designed to protect data once it's inside the secure enclave. But in practice, the first question administrators and researchers ask is more immediate: how does data get in?
tiCrypt supports several ingress methods, each built for a different set of constraints — dataset size, whether the sender has tiCrypt credentials, where the data needs to land, and who owns the process. This post breaks down each option and when to use it.
Choosing the Right Method
Before diving into specifics, it helps to consider four factors:
Volume and cadence — Is this a one-time migration, a recurring data drop, or an iterative refresh during active research?
Sender identity — Is the sender a tiCrypt user, or an external collaborator without credentials?
Landing zone — Should data arrive in a user's Vault for staging, or land directly in a VM?
Operational ownership — Is the researcher handling ingress themselves, or is an administrator managing the intake?
Each ingress method maps to a different combination of these factors.
User-Initiated Methods
Local Upload (to Vault)
The most straightforward option. A logged-in tiCrypt user uploads files from their local workstation directly into their Vault.
Best for: Small to moderate datasets, ad hoc inputs, and interactive workflows — scripts, configuration files, reference data, and incremental additions that will be used inside a secure VM.
Keep in mind: This requires an active session, so it's not suitable for unattended or automated ingestion. Upload speed depends on the user's network connection, making it impractical for multi-terabyte migrations. Data lands in the Vault and needs to be moved to specific VMs as needed.
Inboxes (External Collaborator Drop)
Inboxes solve a common problem: getting data from someone who doesn't have a tiCrypt account. An Inbox is a designated directory within a user's Vault, exposed through an access point that external collaborators can use to submit data.
Inbox access points are configurable with maximum upload size, an expiration date, sender-facing instructions, and a choice of transfer method (URL or SFTP).
URL Upload
Generates a web link that the external collaborator opens in a standard browser. No account, no software — just a link and a file picker.
Best for: Time-boxed collection windows, low-barrier intake from collaborators who need the simplest possible workflow, and situations where issuing credentials to external parties is not desirable.
Keep in mind: Browser uploads work well for small to moderate files but aren't ideal for large or automated transfers. Once uploaded, tiCrypt users review and move the data as needed.
SFTP Upload
Provides sender-specific SFTP credentials (delivered through the Inbox URL) that collaborators use with any standard SFTP client.
Best for: Structured, repeatable transfers and larger datasets where browser uploads fall short. Also more compatible with automation and scripted workflows.
Keep in mind: Senders need an SFTP client or must integrate credentials into scripts, which adds complexity compared to the browser option. Like URL uploads, data lands in the Inbox and must be moved into VMs for analysis.
Inboxes are often the preferred option for third-party intake because they combine lifecycle controls (size limits, expiration) with the ability to accept data without distributing tiCrypt credentials.
Direct SFTP to VM
For authenticated tiCrypt users who need data inside a VM immediately, Direct SFTP to VM skips the Vault staging step entirely. The user generates SFTP credentials that push data straight into the target VM.
This requires the tiCrypt application to be running on the sending machine and an active VM connection to establish the secure pathway.
Best for: Workflows that demand rapid iteration — frequent incremental updates during active analysis, or any scenario where staging data through the Vault adds unnecessary delay.
Keep in mind: Both an active login and an established VM connection are required, so this method cannot run unattended. VM co-owners and managers have full drive access; basic users are limited to their home folder and any directories they've been explicitly granted access to.
Administrator-Initiated Methods
External Drive Builder
For large-scale migrations, the External Drive Builder offers a prepare-seal-deliver workflow. An administrator (or authorized operator) creates a virtual drive outside of tiCrypt, populates it with data, and then seals it using a manifest file. Sealing encrypts the drive and binds decryption and mounting rights to the user specified in the manifest. The sealed drive is then moved into the configured drive pool and made available within tiCrypt.
Best for: Large dataset migrations (5 TB+), project data seeding, and any scenario where data needs to be packaged, verified, and delivered as a complete, ready-to-use drive.
Keep in mind: This method involves a multi-step operational chain (prepare, seal, move, attach), which makes it more deliberate than other options — by design. The drive can be built entirely outside the tiCrypt environment before being introduced.
NFS Mounts Within Specific VMs
Administrators can configure NFS access within specific VMs, allowing data to be copied from institutional or project storage into secured storage inside the enclave (for example, encrypted drives attached to VMs).
Best for: Bridging existing institutional storage into tiCrypt. Particularly useful when external storage remains the source of truth and teams perform controlled copy-in operations as needed, or when transitioning established data pipelines into an enclave workflow.
Keep in mind: Scope control matters. Administrators should define clear access and duration criteria for each mount, with governance focused on the mount lifecycle, access minimization, and regular operational review.
Quick Reference
| Scenario | Recommended Method |
|---|---|
| Small, ad hoc researcher uploads | Local Upload |
| External collaborators without tiCrypt accounts | Inboxes (URL for simplicity, SFTP for repeatable workflows) |
| Active research sessions needing compute-ready placement | Direct SFTP to VM |
| Large-scale onboarding and migrations (5 TB+) | External Drive Builder |
| Institutional storage bridge with controlled copy-in | NFS Mounts Within Specific VMs |
Every Path Leads to the Enclave
tiCrypt's ingress methods cover a wide range of scenarios, from a researcher dragging a file into their Vault to an administrator sealing a multi-terabyte drive for migration. The common thread is that every method is designed to bring data into the secure enclave without compromising the boundary that protects it. The right choice depends on who is sending the data, how much of it there is, and where it needs to go.