Secure by design, not by obscurity.
We publish exactly how we protect your data so that anyone — a customer, an auditor, or a security researcher — can review it. If knowing how it works helped an attacker, it wouldn't be secure.
Our security principles
No obscurity
Our encryption model, key architecture, and threat model are published for review. Security never depends on the design being secret.
Least authority
Every component, token, and person gets the minimum access needed. The server alone can never widen a profile's exposure.
Defense in depth
Encryption, access control, network isolation, and audit logging are independent layers — no single failure exposes plaintext.
No passwords, ever
Passkeys (WebAuthn/FIDO2) plus optional authenticator-app 2FA (TOTP). There is no password to phish, reuse, or leak.
Data minimization
We store the least data necessary, tokenize identifiers, and mask sensitive values by default.
UTC & audited
All timestamps are stored in UTC; security-relevant actions land in a tamper-evident audit log.
What we protect & how
| Data | Protection |
|---|---|
| High-sensitivity fields medical, gov IDs, insurer/policy | Zero-knowledge Client-side encryption where feasible + envelope encryption. Server stores ciphertext it can't read alone. |
| Shared profile fields | Envelope-encrypted per profile (per-profile key), wrapped by your account key. |
| Your private notes & labels | Encrypted with your own key — the other person and the operator can't read them. |
| Public-profile fields | Public Unencrypted by definition, clearly labeled as not covered by the confidentiality guarantee. |
| Consent & DPA records | Append-only, immutable, cryptographically signed. |
| Audit / access logs | Tamper-evident (hash-chained), UTC, minimized. |
Algorithms: authenticated encryption (AEAD) with per-field nonces and Additional Authenticated Data (AAD) binding ciphertext to its owner/field/profile to prevent copy/replay.
Key architecture
Two-key model
A per-account key and a per-profile key. A subscription is a key grant to a profile — not a copy of your data.
Operator can't silently read you
Changing which plaintext a profile exposes requires your account key. The server cannot widen exposure unilaterally.
Split-key delivery
Subscribers submit their public key; profile keys are wrapped to it — so revocation and blast-radius stay bounded.
Hardware-backed keys
Any server-held key material is protected by KMS/HSM, with a recovery path that doesn't weaken the zero-knowledge property.
Responsible disclosure — we want your help
Found a vulnerability? Thank you. We will not pursue legal action against good-faith research that follows this policy.
| security@virtualid.one | |
| Encrypted (PGP) | Fingerprint at /.well-known/pgp-key.txt — please encrypt sensitive reports. |
| Machine-readable | /.well-known/security.txt (RFC 9116) |
| We acknowledge | within 72 hours; triage within 7 days; we coordinate disclosure & offer credit. |
Please do ✓
Please don't ✗
security.txt
Contact: mailto:security@virtualid.one Encryption: https://virtualid.one/.well-known/pgp-key.txt Policy: https://docs.virtualid.one/developers/security Acknowledgments: https://virtualid.one/security/hall-of-fame Preferred-Languages: en Canonical: https://virtualid.one/.well-known/security.txt Expires: 2027-07-14T00:00:00Z
We intend to pursue independent third-party penetration testing and cryptographic review before handling real high-sensitivity identifiers, and to publish result summaries.