Security
Veracium is built so that exposure of any single component does not expose the people on the ground.
Where Veracium stands today — Phase 0 (Beta)
The architecture below describes the target system. Beta currently runs with one KYC custodian, software-stored signing keys, and data-minimisation in place of zero-knowledge proofs. Each item is marked shipped or roadmap. Public launch target: August 2026.
Architecture in one sentence
The system is a blind intermediary: the Journalist* knows who they are, the editor knows what they received, and Veracium operates the layer in between without ever holding both halves in the clear.
How it holds up
- On-device sealing (shipped) — SHA-256 over GPS, timestamp and device ID is computed on the device before any network transmission. We cannot tamper with what we never see in raw form.
- Hardware-backed signing (roadmap, before public launch) — Target: keys held in the device's Secure Enclave / StrongBox, attested via App Attest / Play Integrity, so they cannot be extracted — not even by Veracium. Beta uses software-stored keys; hardware binding is a P1 item before public launch.
- Identity custody (Phase 0 today, multi-custodian target) — Target architecture: the link between Journalist pseudonym and real identity is split across multiple independent custodians via Shamir Secret Sharing, with a 2-of-3 threshold for disclosure. Beta operates with one KYC custodian; additional custodians are being recruited before public launch.
- Tier proofs via data minimisation (zk-SNARKs on roadmap) — Editors only see that a Journalist holds the required tier, not who they are. Today this is enforced through data minimisation on the server. Zero-knowledge proofs (zk-SNARKs) are a Phase 2 research item, not a shipped property.
- EU-hosted, EU-jurisdiction (shipped) — All production data lives on PostgreSQL in Frankfurt (eu-central-1). No US data transfer for operational records.
What we do not protect against
We are explicit about limits. Veracium does not protect against:
- Coerced capture by a hostile party present at the scene.
- An Journalist deliberately staging a scene that is then truthfully sealed.
- A editor republishing the capture without the accompanying certificate.
For each of these, the certificate and chain-of-custody log are designed to make the problem detectable after the fact even if not preventable in the moment.
Reporting a vulnerability
jorg@veracium.io · PGP key fingerprint on /about. We respond within 72 hours and credit responsible disclosure on the project page.
Compliance
Two categories: what we actively monitor, and what is designed into the system.
Actively monitored
GDPR (EU 2016/679)
Data processing register maintained. DPIA on file. EU representative appointed.
EU AI Act
Veracium's use of Claude Vision is classified, monitored against the obligations for limited-risk AI systems, and reviewed quarterly.
NIS2
As a digital infrastructure provider, Veracium is preparing for NIS2 compliance ahead of the German transposition deadline.
Whistleblower protection
Internal channel and external reporting partner for the EU Whistleblower Directive.
Designed in
GDPR by design and by default (Art. 25)
Minimisation, pseudonymisation, and purpose limitation are built into the data model, not bolted on.
Article 85 (journalistic exemption)
The platform is designed to operate within the German implementation of the journalistic exemption while still meeting GDPR's substantive standards where they apply.
C2PA-compatible certificates
Each Veracium certificate is structured to map to C2PA assertions, allowing interoperability with the broader provenance ecosystem.
BSI C5 readiness
The architecture is designed against the BSI C5 catalogue with a view to certification once Veracium operates at the scale where C5 is required.
For specific compliance questions: jorg@veracium.io.