How should you compare encrypted storage and key-custody approaches?
Start with the job, not a product label. The right approach depends on what you need to protect, where the root credential is held, who must administer access, and what recovery and assurance evidence you require.
Compare the questions that change the decision
Encryption is only one part of the decision. Before comparing products, write down what you are protecting, who needs access, and what must remain available after a device loss or staff change. Use the same questions for every option so a software label, hardware device, or enterprise term does not substitute for evidence.
- Where is the root credential held, and who can administer it?
- What is encrypted, and what is outside the stated protection scope?
- How are access, sharing, backup, loss, replacement, and recovery handled?
- Which devices and operating practices are required?
- What evidence supports security, privacy, residency, and certification claims?
- What operator time, procurement, and cost model fit the situation?
A physical key can change the custody model, but it also makes lifecycle questions—loss, replacement, backup, and revocation—more important to investigate. Ask how each approach documents those procedures before you rely on it for sensitive files, credentials, or transaction records. Record answers in writing so procurement, IT, and business owners review the same evidence. Revisit the list whenever a vendor changes sharing, recovery, or support terms during evaluation.
Where can encryption keys be managed?
Key management can sit with a software provider, with the user through a physical device, or with an organization through central KMS or HSM infrastructure. The meaningful question is who can create, use, recover, rotate, or revoke a key in the workflow you are evaluating—not the category label alone.
Does client-side encryption prevent a provider from accessing data?
Client-side encryption describes an encryption model, but it is not by itself a complete answer about provider access. The answer depends on key custody, recovery or escrow design, sharing, support processes, and the documented implementation. Some workflows encrypt content before it reaches a service; others use the term while keys, metadata, or recovery paths remain governed by the provider or account system. Sharing and account recovery can reintroduce access paths that are easy to overlook in marketing language.
Ask for the exact access and recovery boundaries rather than relying on the term alone. Request documentation for what is encrypted, what is not, who can affect keys during support or migration, and how loss or compromise is handled. Compare account recovery, delegated administration, and third-party integrations because each can change effective access even when content is described as encrypted on the client. Ask for written answers about metadata handling, support access, and migration paths before you shortlist a product. Where PrimiDS-specific provider-access conclusions belong, review the security page rather than inferring them from a category label here.
Four approaches, different trade-offs
These are categories, not a ranking. Ask each provider or product the same questions before deciding.
| Approach | Typical reason to consider it | Key questions to investigate | May be a fit when |
|---|---|---|---|
| Software or client-side encrypted storage | A software-led way to store, share, or manage sensitive information | Who holds or can recover keys? How are sharing and account recovery governed? | You want a software-first workflow and its documented custody model meets your needs. |
| Hardware-backed user key custody | A physical device anchors a credential or secret | What happens if the device is lost, damaged, or unavailable? Which workflows require the device? | Physical possession is an important part of your chosen custody model. |
| Encrypted removable storage | Portable encrypted media for a bounded transfer or offline-storage job | How are copies, backups, device loss, and recipient access handled? | Portability or offline handling is central to the use case. |
| Enterprise KMS or HSM infrastructure | Centrally administered key-management infrastructure | Who operates it, how are roles audited, and what integrations or assurance requirements apply? | You have complex administration, procurement, integration, or assurance requirements. |
What should you ask after a password, device, or physical key is lost?
Loss does not have one universal outcome. A password reset, lost device, missing physical key, or unavailable administrator can each trigger different recovery paths, delays, and risks. Document backup, replacement, revocation, and escalation procedures—and who may invoke them—before choosing an approach.
A hybrid model for people who want hardware-backed custody
Early access
PrimiDS is designed to combine encrypted storage and secure communications software with the ToughKey HSM key. Managed Enrolment is the preferred public name for the software. The supplied architecture describes the root cryptographic secret as held in physical hardware rather than as a cloud-recoverable credential—not a claim that other options are unsafe. This model may suit people or owner-led teams who want physical custody without enterprise key infrastructure. Recovery is a live system; the early-access waitlist is the route to enrolment. Product sequence, devices, sharing, replacement terms, and encryption scope are refined as early access opens; hardware is not shipping now.
HSM, security key, and encrypted USB: similar language, different jobs
Security key
A security key commonly supports authentication.
Encrypted removable storage
Encrypted removable storage is media used for portable data.
HSM or KMS
HSM or KMS can refer to hardware or infrastructure used for cryptographic key management.
Their names do not establish the same custody model, recovery process, assurance scope, or workflow fit. Compare the documented job, not the label, and ask how each category handles loss, sharing, and evidence in your exact use case before shortlisting vendors.
Questions worth asking before you choose
Ask a provider, adviser, or internal team to document:
- Who can access or recover keys and under what conditions?
- What happens after a password, device, or physical key is lost?
- How are backups separated from recovery procedures?
- What does “client-side encryption” mean in this specific workflow?
- What assurance evidence applies to the exact product and deployment scope?
- Does the approach fit one person, a small team, or an enterprise operating model?
Design claims and independent assurance are not the same
Disclosure
PrimiDS is in early access. Primi is not currently FIPS 140-2/140-3 or Common Criteria certified. A product’s architecture, documentation, independent testing, operational controls, and certification scope should be assessed separately. Do not treat an HSM label, encryption terminology, or a physical key as proof of a particular certification or outcome.
Evaluate the model now; follow early access as it opens
Join the waitlist for early-access updates about PrimiDS and ToughKey. Availability, supported workflows, and commercial terms are confirmed as early access opens.