Security & Governance
Every data breach starts with an implicit trust assumption that shouldn't have been there, a service that wasn't authorized, an API call that wasn't logged, a permission change that nobody reviewed. VDX eliminates implicit trust from your identity infrastructure. Every command is policy-checked before execution. Every action is recorded in a tamper-evident audit trail. Every decision is traceable across services, tenants, and time.
This isn't a security layer bolted onto the platform. It's how the platform works. The same governance model applies whether you're issuing a credential, verifying a presentation, signing a document, or returning a query result. Nothing executes without authorization, nothing happens without a record.
Policy-Driven Authorization
Before any command executes, issuing a credential, reading an identity, signing a document, querying a record, it passes through the policy enforcement layer. The decision is made by an external policy engine, not by application code.
Three policy engines are supported. Cedar (AWS) provides formally verifiable policies that can be mathematically proven correct, you can ask "is there any scenario where an unauthorized user can access this resource?" and get a definitive answer. Open Policy Agent uses the industry-standard Rego language, widely adopted in cloud-native environments. Any AuthZEN-compliant PDP works out of the box.
What makes this different from role-based access control scattered through code:
- Policies are data, not code. Update who can do what without redeployment. Different tenants can have entirely different policy sets.
- Dual-principal evaluation. Both the end user AND the calling service are authorized on every request. A compromised service can't escalate its own privileges.
- Step-up authentication. Policies can require higher assurance for sensitive operations, viewing a record needs
low, but exporting it needshigh. The platform challenges the user automatically. - Fail-closed by default. If the policy engine is unreachable, everything is denied. No security degradation under failure.
- Progressive rollout. Log-only mode lets you see what would be denied before enforcing, validate policies against production traffic without breaking anything.
Immutable Audit Trail
Every operation produces an audit record. Not just "user X did Y", the full context: who, what, when, why it was allowed (or denied), how long it took, which service handled it, and the distributed trace ID linking it to every other operation in the request chain.
The audit pipeline automatically enriches events with tenant and actor context from the session, redacts sensitive data (passwords, tokens, API keys are stripped before persistence), and writes to an append-only store where records cannot be modified or deleted, not even by administrators.
Tamper evidence goes further: every audit event is hash-chained to the previous one. Modifying any event breaks the chain. Periodic signed checkpoints provide independent verification points. An auditor can prove that no records were altered between any two points in time.
What Gets Recorded
| Event type | What it captures |
|---|---|
| Command execution | Every business operation, credential issuance, identity verification, document signing, data queries |
| Authorization decisions | PERMIT and DENY with policy engine reasons, including which rules matched |
| Authentication events | Wallet presentations, OIDC logins, step-up challenges, session lifecycle |
| Data access | Who read what, from which service, at what assurance level |
| Configuration changes | Policy updates, tenant settings, credential schema modifications |
| Security events | Failed authentication attempts, suspicious patterns, credential revocations |
SIEM Integration
Audit records export to your existing security infrastructure in three formats:
- JSON: for Elasticsearch, Splunk, Datadog, Loki, and modern log platforms
- CEF (Common Event Format), for ArcSight, QRadar, and legacy SIEM systems
- OCSF (Open Cybersecurity Schema Framework), the emerging standard for security telemetry
Export is asynchronous, it never blocks command execution. Failed exports retry with exponential backoff and dead-letter queuing so nothing is silently lost.
End-to-End Tracing
A single user action, presenting a credential, signing a document, verifying an identity, might flow through multiple microservices. Without tracing, investigating an incident means correlating logs from different services by timestamp and hoping.
VDX uses OpenTelemetry with W3C Trace Context propagation. A single trace ID follows the request from the API gateway through every service that participates. Spans within the trace show where time was spent. The trace ID appears in every audit record, every log line, and every SIEM export, so investigating an incident starts with one ID and reveals the complete picture.
Cross-Domain Security Signals
When a credential is compromised, a session is revoked, or an account is disabled, every system that trusts that identity needs to know, immediately, not hours later.
VDX implements the OpenID Shared Signals Framework (SSF) for real-time security event exchange. CAEP events handle session revocation and token claim changes. RISC events handle account compromise, disablement, and purge. All signals are transmitted as signed Security Event Tokens (SETs) with replay protection.
This means VDX doesn't operate in isolation. When an upstream identity provider detects a compromise, the signal propagates to VDX, which revokes sessions, invalidates cached decisions, and notifies downstream systems, all within seconds.
Data Protection
Identity data is encrypted at rest with per-identity keys. The organization can access data through its KMS-wrapped grant. The wallet holder can access it through their public key. Optional knowledge-based grants add passphrase protection.
No plaintext identifiers in the database. External identifiers (wallet keys, email addresses, institutional IDs) are stored as HMAC hashes. Canonical attributes are encrypted with AES-256-GCM. Even with full database access, an attacker sees only ciphertext and hashes.
GDPR by architecture:
- Crypto-shredding: destroying one key makes all data for an identity irrecoverable. No data migration, no record-by-record deletion. O(1) erasure.
- Selective disclosure: holders choose which claims to reveal per presentation. The verifier never sees more than what's needed.
- Consent-as-grants: access grants carry purpose, validity period, and revocation. Revoking consent = revoking the grant = immediate access termination.
- Data portability: export command bundles all data for an identity in a portable format.
Governance at Every Layer
The same governance model applies across all platform operations:
| Layer | How governance applies |
|---|---|
| Credential issuance | Policy check before issuing. Audit record of what was issued, to whom, by which authority. |
| Credential verification | Policy check on what to accept. Audit record of what was verified, from whom, with what assurance. |
| Identity matching | HMAC-hashed links, no plaintext. Audit record of matching decisions and IDV outcomes. |
| Data access | Policy check on every read/write. Encryption at rest. LoA-gated decryption grants. |
| Configuration changes | Policy check on who can modify settings. Audit record of every change with before/after values. |
| Service-to-service | mTLS and workload identity. Dual-principal authorization. No shared secrets. |
The result is a platform where every business decision, from "should we issue this credential?" to "should this service access this record?", goes through the same policy-audit-trace pipeline. No exceptions, no bypasses, no implicit trust.