Trust & Security
Security that's
verifiable by design.
HexVault is built on a single architectural premise: the server must not be trusted with your secrets. All vault data is encrypted client-side before transmission. A complete breach of our infrastructure would expose only ciphertext we cannot decrypt. This page documents every security decision — so you can verify, not just trust.
Zero-knowledge encryption
AES-256-GCM + Argon2id
Granular RBAC
JIT access grants
Directory sync
SOC 2 planned H2 2026
UK GDPR compliant
01 Security posture
Current status
An accurate, up-to-date view of our compliance and certification status. We don't overstate what we have.
UK GDPR
Compliant
ICO registered. Data subject rights, breach notification, and retention policies implemented.
Encryption
Production
AES-256-GCM client-side, Argon2id KDF, per-entry HKDF. Inspectable in DevTools.
Zero-knowledge
Architectural
Server never sees plaintext. Enforced at protocol layer, not policy.
SOC 2 Type I
In progress
Controls mapped. Audit engagement planned H2 2026.
Pen test
Planned
Independent third-party test scheduled prior to SOC 2 audit.
ISO 27001
Roadmap
ISMS framework in place. Certification after SOC 2 Type I.
Honest baseline: We do not currently hold SOC 2 or ISO 27001 certifications — both are scheduled for H2 2026. Our controls are implemented and documented here. Enterprise customers requiring certified status before onboarding should contact us to discuss timeline and interim assurance.
02 Architecture
Zero-knowledge by construction
Every vault operation is structured so that encryption and decryption happen entirely on the client device. The server functions as an encrypted storage layer — it can authenticate you, but it cannot read what you store.
Verification: The client-side encryption implementation is unminified and inspectable in browser DevTools. Open the Network tab, watch a credential write — only ciphertext and IV transit the wire. The master password is never submitted.
03 Encryption specification
Every layer documented
L1
Master password — never transmitted
Argon2id · memory=65536 KiB · iterations=3 · parallelism=4 · output=256 bits
Derives the vault root key entirely on-device. The password itself never leaves the browser.
L2
Vault root key → per-entry keys
HKDF-SHA-256 · input=vault_root_key · info=entry_id+timestamp · output=256 bits
Each credential is encrypted with its own derived key. Compromise of one entry key cannot be leveraged to derive others.
L3
Credential encryption
AES-256-GCM · IV=96-bit random · auth tag=128-bit
GCM provides both confidentiality and integrity. Any tampering with the ciphertext is detected and rejected client-side on decrypt.
L4
Org vault key — team credentials
ECDH P-256 · each member receives wrapped_org_key encrypted to their ECDH public key
The org vault key is distributed cryptographically to each member. Revoking a member's grant makes org credentials inaccessible immediately — no rotation required.
L5
Authentication — server side
bcrypt · cost=12 · TOTP RFC 6238 with replay protection · WebAuthn FIDO2
bcrypt is intentionally slow. TOTP window is ±30s with used-code deduplication. WebAuthn credentials are bound to origin and cannot be phished.
L6
Transport
TLS 1.3 via Cloudflare · HSTS max-age=31536000 · preload eligible
All traffic enforced over TLS 1.3. HSTS prevents downgrade attacks. HTTP requests are redirected at the edge.
L7
Breach monitoring — k-anonymity
HIBP API · SHA-1(password) → first 5 chars sent · ~1000 matches returned · local comparison
Neither HexVault nor HIBP receives a password or full hash. Only a 5-character prefix is transmitted. The full result set is compared locally.
04 IAM controls
Identity & Access Management
The IAM layer sits above the encryption layer. Access decisions are enforced server-side — a member with no permission on a folder simply does not receive ciphertext for credentials within it.
Granular RBAC
Read / Write / Admin per resource
Permissions assigned per folder or credential, per user or group. Folder-level mode: open or restricted. Enforced at the query layer — no ciphertext returned for unauthorised subjects.
LiveJust-in-Time Access
Time-limited grants, auto-expiring
Members request access with reason and duration. Admin approves in one click. Grant auto-expires. Sessions remain active but vault access is revoked at expiry. Full audit trail.
LiveDirectory Sync
Google Workspace & Microsoft 365
OAuth refresh tokens stored securely. Background job polls directory every 15 minutes. Members absent from directory are suspended: deactivated, sessions revoked, admins notified. Zero-user guard prevents mass-deprovision on API error.
LiveDevice Posture
Org-wide device trust visibility
Admin dashboard shows every trusted device across the org — OS, browser, IP, location, last seen. Risk flags: no 2FA, inactive 30+ days, low security score. Admin can revoke any device with one click.
LiveSSO / SAML 2.0
Okta, Azure AD, Google Workspace
SAML 2.0 with any compliant IdP. SCIM provisioning. SP-initiated and IdP-initiated flows. Enterprise plans only.
EnterpriseMulti-Party Approval
Quorum-based admin actions
Destructive org actions require quorum approval with time-delay and cancellation window. No single admin can act unilaterally on high-risk operations.
EnterpriseService Accounts
Machine identities for CI/CD
Non-human identities scoped to specific folders. Read-only or read-write. Bearer token auth. Revokable instantly. Verified against org membership on every request.
Team+Audit Log
Immutable, SIEM-ready
Every access, permission change, JIT grant, and policy update logged with timestamp, actor, and IP. CSV export and signed webhooks for SIEM integration. 12-month retention.
Team+Cryptographic offboarding: When a member's org key grant is revoked — via directory sync, JIT expiry, or manual action — their access to org vault credentials is severed cryptographically. They hold no key that can decrypt org credentials. Credential rotation after departure is optional, not urgent.
05 Infrastructure
Hosting & deployment
# Stack
Application: Flask / Python — Gunicorn workers
Database: PostgreSQL — encrypted at rest
Sessions: Redis — server-side session store
Containers: Docker · non-root · read-only rootfs · no-new-privileges
Proxy: Traefik · 120 req/s global · 5 req/s auth paths
Edge: Cloudflare — TLS termination · DDoS · WAF
Hosting: United Kingdom
Backups: Encrypted · daily · point-in-time recovery
Containers run as non-root with read-only root filesystems. The PostgreSQL application user is restricted to DML only — it cannot DROP, ALTER, or CREATE tables. Dependencies are pinned. Data is hosted entirely in the United Kingdom.
06 Control inventory
Security controls
| Control | Implementation | Status |
|---|---|---|
| Encryption at rest | AES-256-GCM per vault entry, client-side. PostgreSQL at-rest encryption for metadata. | ✓ Live |
| Encryption in transit | TLS 1.3 via Cloudflare. HSTS max-age=31536000. | ✓ Live |
| Key derivation | Argon2id 64 MB · 3 iter · 4 threads. Master password never transmitted. | ✓ Live |
| Per-entry key isolation | HKDF-SHA-256 per credential. Single entry compromise cannot expose others. | ✓ Live |
| Authentication | bcrypt cost=12. TOTP (RFC 6238) with replay protection. WebAuthn/FIDO2. | ✓ Live |
| Session management | HttpOnly · Secure · SameSite=Lax. Server-side Redis store. Configurable inactivity timeout. | ✓ Live |
| Granular RBAC | Read/write/admin per folder/credential/user/group. Enforced at query layer. | ✓ Live |
| JIT access | Time-limited grants, admin approval, auto-expiry, audit trail. | ✓ Live |
| Directory sync | Google Workspace and Microsoft 365. 15-min polling. Auto-suspend on departure. | ✓ Live |
| Device posture | Org-wide device trust dashboard. Admin revoke. Risk flags per member. | ✓ Live |
| Rate limiting | Login: 10/15 min. API: per-route via Redis. Account lockout after threshold. | ✓ Live |
| CSRF protection | Per-session token on all state-changing requests. | ✓ Live |
| Content Security Policy | script-src 'self'. No unsafe-inline. SHA-256 hashes for necessary inline scripts. | ✓ Live |
| Container hardening | Non-root · read-only rootfs · no-new-privileges · pinned dependencies. | ✓ Live |
| DB privilege separation | App user DML-only. Migrations run under separate elevated connection. | ✓ Live |
| Audit logging | Credential access, login events, org changes, JIT grants. SIEM-ready via webhooks. | ✓ Live |
| Breach monitoring | k-anonymity HIBP. 5-char SHA-1 prefix only. No plaintext or full hash transmitted. | ✓ Live |
| Multi-party approval | Quorum-based approval for destructive admin actions. | ✓ Live |
| Penetration test | Independent third-party test scheduled H2 2026. | ◐ Planned |
| SOC 2 Type I | Audit engagement planned H2 2026. | ◐ Planned |
| ISO 27001 | ISMS framework in place. Certification after SOC 2. | ○ Roadmap |
07 Data handling
What we store — and what we can't read
| Category | What we store | Retention |
|---|---|---|
| Vault credentials | AES-256-GCM ciphertext + IV only. We cannot decrypt. | Account lifetime + 30-day deletion window |
| Secure notes | AES-256-GCM ciphertext only. | Account lifetime + 30-day deletion window |
| Account data | Email, bcrypt hash, username, subscription status. | Account lifetime + 30-day deletion window |
| Session data | Encrypted session token (Redis). No vault key stored server-side. | Expires on logout or inactivity timeout |
| Directory sync tokens | OAuth refresh tokens for Google/Microsoft sync. Encrypted at rest. | Until sync is disconnected |
| IP addresses | Per-session and per-API for security monitoring. | 12 months |
| Audit logs | Credential access events, login events, org changes, JIT grants. | 12 months |
| Billing data | Stripe customer ID and subscription ID only. No card data stored. | Account lifetime + 7 years (legal requirement) |
| Breach check data | 5-char SHA-1 prefix only. Not stored — single API call per check. | Not stored |
| Device trust records | Device fingerprint, browser, OS, IP, location, last seen. | Until revoked or account deletion |
HexVault Ltd acts as a data processor for encrypted vault data and as a data controller for account and billing data. All data is hosted in the United Kingdom.
08 Sub-processors
Third-party processors
We have Data Processing Agreements with each sub-processor below. Customers will be notified of changes with 30 days notice. We do not use advertising networks, social media tracking pixels, or analytics sub-processors.
| Processor | Purpose | Data shared | Location |
|---|---|---|---|
| Stripe | Payment processing | Email, billing address, Stripe customer ID | US (UK IDTA) |
| Postmark | Transactional email | Email address, email content | US (UK IDTA) |
| Cloudflare | DDoS, CDN, DNS, TLS | IP addresses, request metadata | US (UK IDTA) |
| HIBP | Breach monitoring (k-anon) | 5-char SHA-1 prefix only — no passwords | US (no personal data) |
| Sentry | Error monitoring (vault ops excluded) | Error stack traces, no vault data | US (UK IDTA) |
09 Compliance
DPA & compliance documentation
Enterprise and Team customers requiring a signed Data Processing Agreement under GDPR Article 28 can request one. Standard DPA available within 2 business days. We also respond to security questionnaires for enterprise procurement within 5 business days.
Request a Data Processing Agreement
Standard DPA available immediately. Custom terms negotiable for Enterprise.
10 Incident response
If something goes wrong
| Phase | Action | Timeline |
|---|---|---|
| Detection | Automated monitoring via Sentry, rate-limit alerts, and authentication anomaly detection. | Continuous |
| Containment | Affected sessions revoked, compromised accounts locked. | <15 min of detection |
| ICO notification | Within 72 hours if breach poses risk to data subject rights (UK GDPR Article 33). | 72 hours |
| Customer notification | Affected customers notified without undue delay once breach confirmed. | As soon as practical |
| Post-incident review | Root cause analysis. Published summary for significant incidents. | 30 days |
Zero-knowledge incident note: A breach of HexVault's servers would not expose your vault passwords — only encrypted ciphertext we cannot decrypt. We would still notify you of any breach that exposed account metadata (email addresses, subscription status). This is a cryptographic constraint, not a policy claim.
11 Responsible disclosure
Report a vulnerability
If you discover a security vulnerability in HexVault, report it privately. We acknowledge within 48 hours and keep you informed throughout remediation.
# Contact
Email: [email protected]
# Our commitments
• Acknowledge within 48 hours
• Status updates throughout
• Credit in release notes (if desired)
• No legal action for good-faith research
# Patch SLA
Critical: 7 days
High: 30 days
Medium: 90 days
12 Contact
Get in touch
Security & vulnerability reports
Security disclosures, DPA requests, security questionnaires, and compliance enquiries.
Privacy & data subject rights
GDPR requests, data deletion, access requests, and privacy policy enquiries.
General & enterprise sales
Enterprise onboarding, custom contracts, and general product enquiries.
Legal entity
HexVault Ltd
Registered in England & Wales. Last updated: April 2026.