Enterprise Security Overview
Enterprise deployments inherit all the security properties of the SaaS platform plus additional controls specific to self-hosted infrastructure.
Shared Security Properties
All Veriproof deployments — SaaS and enterprise — share these security properties:
- End-to-end encryption: Session payloads are encrypted with AES-256-GCM using per-data-subject keys derived from a pepper key via HKDF. Veriproof cloud infrastructure never holds the pepper key in Hybrid/LocalFirst/Disconnected modes.
- Zero-knowledge for the platform operator: In Hybrid mode, Veriproof receives only 32-byte hashes. It is mathematically impossible for Veriproof to reconstruct any session content from these hashes.
- Immutable blockchain anchoring: Commitment anchors on Solana are permanent and publicly verifiable without trusting Veriproof.
- Least-privilege RBAC: Five distinct roles with minimal cross-boundary permissions.
Enterprise-Specific Security Controls
Customer-Controlled Keys
In Hybrid, LocalFirst, and Disconnected modes, you own and manage the pepper key and all per-data-subject encryption salts in your Azure Key Vault. Neither Veriproof nor any third party has access to your Key Vault (assuming correct Managed Identity configuration with no external role assignments).
This means:
- Data cannot be accessed by Veriproof even under legal compulsion (they do not hold the keys)
- You can independently rotate or destroy keys without involving Veriproof
- GDPR erasure is performed by destroying a per-subject salt in your Key Vault
Network Isolation
Your Customer Portal API and PostgreSQL instance can be deployed entirely within an Azure Virtual Network with no public endpoints. Only the Ingest API needs to make outbound HTTPS calls (for commitment submission) — these can be routed through a NAT Gateway or egress proxy.
Veriproof never initiates inbound connections to your infrastructure.
Deployment Context Integrity
The signed deployment-config.json prevents unauthorized re-initialization of a configured portal. See Deployment Context.
Audit Log Tamper Resistance
In enterprise mode, audit logs are written to your PostgreSQL instance. Protect them using PostgreSQL row-level security: grant INSERT to the Function App’s Managed Identity but not UPDATE or DELETE. This ensures audit entries are append-only even if the Function App identity is compromised.
Threat Model
| Threat | Mitigation |
|---|---|
| Veriproof insider accesses session data | Hybrid mode: Veriproof never receives session content |
| Attacker compromises Veriproof cloud | Hybrid/LocalFirst: no session data stored in Veriproof cloud |
| Attacker compromises your PostgreSQL DB | All payloads AES-256 encrypted; keys in Key Vault |
| Attacker compromises your Key Vault | Enable purge protection; monitor Key Vault access logs |
| Replay attack on commitment API | Each commitment carries a unique session ID; duplicates rejected |
| Portal re-initialization attack | Signed deployment-config.json; database is_setup_complete flag |
| API key compromise | Immediate revocation via DELETE /v1/customer-keys/{id} |
Compliance Certifications
Veriproof SaaS is certified for:
- SOC 2 Type II — security, availability, and confidentiality trust service criteria
- GDPR — compliant data processing agreement available
- EU AI Act — transparency record-keeping capabilities
In enterprise self-hosted deployments, your infrastructure must be independently certified for your compliance targets. Veriproof provides evidence packages to support your certification audits.
See also: