Inspect the security model
PrimiDS is in early access. This page is the inspectable centre for architecture, data handling, access, hardware, recovery, assurance, disclosure, resources, and status — written for security due diligence rather than marketing reassurance.
Architecture
PrimiDS is designed to keep the root cryptographic secret in the ToughKey physical key rather than as a cloud-recoverable credential. That is an architecture assertion, not a guarantee that compromise cannot affect a user. Primi is not currently FIPS 140-2/140-3 or Common Criteria certified.
| What the architecture is designed to do | What has been independently verified |
|---|---|
| Hold the root secret in ToughKey, not as a cloud-recoverable credential. | No independent architecture review supplied for publication. |
| Pair ToughKey with PrimiDS for encrypted storage and secure communications. | Independent testing not yet verified for publication. |
| Use AWS/S3 for hosting and object storage. | Regions, residency, and privacy operations not verified for publication. |
| Recover access, set permissions, and retain audit history as live capabilities. | Independent certification unconfirmed. See Disclosure. |
Data Handling
Design versus confirmed
PrimiDS is designed for encrypted storage and secure communications. AWS/S3 is the hosting and object-storage environment for files and metadata at rest in the intended model. Encryption protocol, encryption boundary, hosting regions, data residency, subprocessors, retention, deletion, incident response, and privacy terms are not yet verified for publication — treat every detail here as design intent rather than an operating commitment. Do not infer market availability, a specific region list, or residency choices from the provider choice alone. Where a control is described as designed or intended, that language describes architecture direction rather than evidence that the control is built, tested, or operating in production today. Subprocessor lists, data-processing agreements, and published privacy policies are part of the evidence gap until supplied. Incident-response playbooks, breach notification timing, and customer notification channels are likewise unconfirmed. Questions about provider access boundaries sit in Access; certification language sits in Disclosure.
Access
Permissions and audit are part of the live PrimiDS system: who may open what, who may revoke it, and what security events are retained for review. That live status is not a statement that hardware is for sale today; the early-access waitlist is the route to using those capabilities. Whether Primi, an infrastructure provider, or another party can decrypt a particular file is not independently verified for public disclosure; do not read the permissions model as proof of client-side encryption or zero-knowledge design. Access control here means product permissions and audit history; it does not mean every threat actor is blocked or every endpoint is safe. Provider decryptability, administrative access, and lawful-request handling remain evidence gaps this page labels plainly rather than resolving by implication.
Hardware
ToughKey is the physical key. It is designed to hold the root cryptographic secret in hardware rather than as a credential recoverable from the cloud alone. ToughKey is powered by LokBlok; that ingredient relationship does not transfer LokBlok certifications to Primi and must not be read as Primi inheriting ingredient assurance. An HSM is a hardware security module — here it describes ToughKey’s role in custody, not a certification badge. ToughKey is not a passkey, not an authentication token, and not a substitute for account sign-in credentials. Passkeys and cloud-recoverable credentials can be convenient for sign-in, but they are not designed to replace hardware custody of a root secret. Published materials describe intended hardware custody; they do not prove tamper resistance, supply-chain integrity, or independent hardware evaluation. Supported devices, manufacturing status, and fulfilment timing are refined as early access opens.
In dedicated hardware
Root cryptographic secret
In the cloud
Encrypted storage and secure communications
Planned architecture
Recovery
Live system
A physical key can be lost, damaged, or stolen — ordinary operational risks, not hypothetical edge cases. Recovery is part of the live PrimiDS system, not a research question, and not a statement that hardware is for sale today. The early-access waitlist is the route to using recovery alongside permissions and audit. Beneficiary, executor, or post-death access is not confirmed. Supported devices, backup procedures, revocation timing, and replacement logistics are refined as early access opens. Loss or theft does not automatically imply total data loss in the intended model, but the published recovery procedure is not supplied here. For short answers on recovery and certification boundaries, see recovery and certification questions. Do not treat this section as a step-by-step recovery runbook.
Assurance
Evidence status
The intended architecture is designed to reduce reliance on remotely recoverable root credentials. It does not eliminate endpoint compromise, phishing, user error, insecure business processes, malicious insiders, implementation defects, service availability problems, ransomware, payment diversion, or every other threat. Product audit history is live; that is operational record-keeping, not a third-party security audit, penetration test, or certification. Primi has not supplied public evidence of a completed independent review, penetration test, third-party audit, vulnerability programme, or implementation test. Until such evidence is published, independent testing is not yet verified for publication and no assurance seal should be inferred from architecture language alone.
Disclosure
Certification status
Primi is not currently FIPS 140-2/140-3 or Common Criteria certified. HSM, hardware-backed, access-control, and zero-trust terminology on this page are descriptions of architecture concepts; they are not certifications, ratings, or compliance badges. Publishing a design diagram or custody illustration does not create a certificate. Any future certification statement should name the certificate, standard version, holder, product or module, scope, and current status rather than relying on shorthand. Until then, treat every assurance adjective as descriptive language bounded by the evidence panels elsewhere on this page.
Resources
Review how PrimiDS and ToughKey work together, the FAQ, or send a security question for an unanswered technical issue.
Who controls the root secret?
The architecture places it in the physical ToughKey key.
Can Primi or a hosting provider decrypt files?
Not independently verified for public disclosure.
What happens if ToughKey is lost or damaged?
Recovery is part of the live system. The early-access waitlist is the route to it; that is not a purchase or a shipping date.
What testing has been completed?
No public independent-testing record has been supplied for this page.
Is Primi certified?
No. Architecture language is not a certificate. See Disclosure.
Where will data be hosted?
AWS/S3 is the hosting environment in the intended model; region and residency choices are not yet confirmed for publication.
Status
Live / Designed / Unconfirmed
PrimiDS is in early access. Live in the system today: recovery, permissions, and audit. Designed for encrypted storage and secure communications under ToughKey custody in the intended model. Unconfirmed for publication: independent testing, certification, hosting regions, residency, encryption protocol, encryption boundary, subprocessors, retention, deletion, incident response, supported devices, and beneficiary access. This three-state summary is the page’s honest status frame — live capabilities are real product functions, designed items describe direction, and unconfirmed items are evidence gaps rather than silent promises. The early-access waitlist is the route to the live capabilities; it is an expression of interest, not a purchase or shipping commitment. Ask a security question for a due-diligence gap this page does not close.
Ask a specific security question
Ask about the architecture, the live recovery, permissions and audit model, hosting plans, certification status, or any evidence gap this page labels unconfirmed. This is a monitored due-diligence security-question route, not a purchase, not a shipping date, and not a promise of hardware in hand.


