They aren't stored at rest. DVE derives keys on demand from passphrase and chain state at the moment of authenticated access. The cryptographic boundary begins at the local agent on the endpoint — passphrase entry never leaves the device — and ends when the session closes and key material is explicitly wiped from memory using platform-native secure wipe, not garbage collection. Nothing persists between sessions that can be exfiltrated.

Three independent barriers. First, credentials don't exist in the database — only Heisenberg double-encrypted ciphertext blobs with metadata obfuscated and padded to uniform length, defeating traffic analysis. Second, decryption requires reconstructing the valid chain state through every prior block — an exfiltrated snapshot at block N is useless without the complete chain history and the passphrase. Third, key derivation uses dual Argon2id KDF — the second pass binds the chain state, meaning the derived key at step N is irreproducible without both the passphrase and the exact chain state at that point. A snapshot gives an adversary encrypted data they cannot key.

DVE's quantum defense operates at two levels — primitive and architectural — and the architectural argument is the stronger of the two.

At the primitive level: DVE does not rely on PKI or asymmetric public-key cryptography for credential protection. The encryption model is symmetric AES-256-GCM with keys derived via Argon2id — both are considered quantum-resistant at current key sizes. That's the standard claim any modern security product can make.

The architectural claim is more significant. The primary quantum threat against current credential systems is harvest-now-decrypt-later — an adversary captures encrypted vault data today and waits for quantum decryption capability to mature before breaking it. DVE eliminates this attack surface entirely because there is no persistent encrypted vault to harvest. Credentials derive on demand from passphrase and chain state at the moment of authenticated access, exist for the duration of the session, and are then destroyed. A quantum computer that could break AES-256-GCM in minutes is still useless against a key that existed for 30 minutes and was wiped an hour ago. There is nothing to harvest and nothing to decrypt later.

Rotation strengthens this further. Each passphrase rotation produces a new chain era with new key material derived independently from a new passphrase and a new chain state. An adversary who captured encrypted blobs from a previous chain era gains nothing from breaking that era's keys — the current era's credentials were re-derived independently, and the old era is sealed. The quantum attack surface resets with every rotation. DVE provides rotating, session-scoped, chain-state-bound key derivation that eliminates the persistent encrypted target quantum attacks require — now and in the future.

Cryptographic trust is distributed to the endpoint by default. All sensitive operations — passphrase entry, key derivation, chain state reconstruction — occur on the local agent. The relay infrastructure never sees key material in the clear. For break-glass and group key recovery scenarios, the Hawking n-of-m XOR ceremony distributes trust across M-of-N keyholders — no single person holds a complete key. Normal authenticated sessions do not require a Hawking ceremony. There is no HSM dependency and no single point of cryptographic compromise.

Configurable per deployment, with DVE-enforced bounds. Human credential keys exist only for the duration of an active session — destroyed immediately on session end via native secure wipe. Machine credential tokens have an admin-set TTL with a hard minimum of 5 min and a hard maximum of 24 hr, default 1 hr. Token expiry triggers re-derivation, not re-authentication. No key material survives a session boundary.

Machine identity in DVE is tracked via a persistent agent-generated device ID, hashed as a machine_id_hash and stored in the fleet registry. This provides an operational record of registered machines but does not currently enforce a hard block on token replay from an unregistered device — that enforcement layer is on the roadmap. IP context changes for service account secret access are detected and flagged as audit anomalies; a new IP for the same service account token generates a high-severity anomaly event in the audit chain. General impossible travel detection and geographic access gating are planned features. What DVE does guarantee is that a replayed session token yields nothing decryptable — the attacker still needs the passphrase-derived keys that exist only on the registered endpoint.

A successful session hijacking attack against the DVE Admin Dashboard gives an attacker access to encrypted blobs, operational metadata, and administrative functions — but not to credential values or encryption keys. Those never leave your endpoint.

DVE does not claim to prevent session interception — no web application can make that guarantee. What DVE guarantees is that a stolen session yields nothing decryptable. The attacker gets the same thing a subpoena gets: UUIDs, hashes, and encrypted blobs requiring keys that exist only on your devices.

For a specific set of high-risk administrative actions — weakening security policy, bulk user deprovisioning, passphrase rotation, support token issuance, and Hawking group reconfiguration — DVE requires Ed25519 dual-authorization cryptographically signed by the agent. A proxy attacker holding only a session cookie cannot forge that signature. The action cannot proceed without the second signer’s agent key, which never leaves their endpoint.

This is impact containment by design, not session security by promise.

FIDO2/WebAuthn is on the DVE roadmap as a post-launch addition. At launch, phishing resistance is achieved structurally — passphrase entry occurs on the local agent out-of-band from the browser, eliminating the browser-based phishing surface entirely. There is no web form that a phishing proxy can intercept. Admin policy can disable all non-agent authentication paths, removing fallback vulnerabilities at the policy layer.

DVE does not depend on a public ledger for access validation. Authentication and credential access are resolved locally — the agent holds the cached permission chain state and all cryptographic operations happen on the endpoint. The relay is not in the hot path for every access event. DVE genesis blocks use CSPRNG-generated entropy as the cryptographic anchor. This approach was chosen over public blockchain anchoring — which would require internet access at genesis time and create an external dependency — and over zero-initialized anchors, which leak information about the chain’s starting state. The CSPRNG genesis anchor is verifiable against PhantomKey’s genesis block registry without any external dependency. Access never waits on external network consensus.

DVE does not use external public-chain anchoring — that approach was considered during design and rejected because it would require internet access at genesis time and create an external dependency. Genesis blocks use CSPRNG-generated entropy as the cryptographic anchor, verifiable against PhantomKey’s genesis block registry without any third-party network. Authentication and access control do not depend on external verification services. The internal five-chain zipper provides tamper-evidence for access control independently. If external auditors or registry services are temporarily unavailable, local agent operation and relay authentication continue unaffected; chain integrity is validated from the append-only hash chains and genesis registry when connectivity returns.

Yes. SCIM 2.0 provisioning and deprovisioning is a supported add-on module. HR system changes — new hires, role changes, terminations — propagate automatically to the DVE permission chain. Every provisioning event is chain-recorded with source, timestamp, and the permission state at the time of change. The SCIM integration is IdP-agnostic — it works with any upstream directory that speaks the standard.

The SSO/LDAP add-on module supports both LDAP/Active Directory connectors for on-premises environments and SAML 2.0 for cloud IdPs simultaneously. Identity attributes from both sources are normalized into the DVE permission chain user record — department, role, location, manager hierarchy — making the permission chain the single authoritative access record regardless of where identity originates. v1 is cloud-hosted relay only; on-premises DVE deployment is a v2 roadmap item for organizations requiring full infrastructure separation.

Revocation is a permission chain event — it takes effect on the next agent check-in cycle, which is admin-configurable with a default that can be set to near-real-time. For immediate revocation, the admin can force-expire all active tokens for that user, which the relay enforces instantly on any subsequent request. The revocation event and its timestamp are audit-chain-recorded and immutable. Propagation to federated SSO applications follows the IdP session invalidation model — SCIM-connected directories receive the deprovisioning event on the same cycle.

At launch, the policy layer supports three org-level controls: agent mode enforcement (requiring the DVE agent for all access), fail-closed behavior (denying access when the relay is unreachable), and secret vending mode (controlling CI/CD secret access). Anomaly detection for service account secret tokens covers volume thresholds, concurrent token limits, IP context changes, and rotation grace windows — each flagging audit events at configured severity levels without hard-blocking. Full conditional access policy signals — IP allowlists, VPN status, geographic boundaries, time-of-day windows, and MFA-method requirements — are on the post-launch roadmap as the policy engine matures. Every policy state at each access event is recorded in the permanent audit chain.

DVE has seven named roles — Super Admin, Security Admin, IT Admin, CISO, Auditor, Member, and Executive Attestor — with no single role holding all capabilities. Super Admin cannot approve their own access or unilaterally export audit logs. Security Admin cannot provision users. IT Admin cannot modify security policy. CISO — oversight role; read access to policy, settings, and reports; can respond to pending sign-off requests and initiate on-demand audit exports (dual-auth required); no provisioning or policy-write access. Auditor — audit read path; can view the audit chain, generate compliance reports, and initiate on-demand audit exports (dual-auth required); no configuration, user, or policy writes. Executive Attestor — a governance-only role with no operational access; designated to countersign high-risk dual-authorization actions. Cannot initiate actions, view credentials, or modify configuration. Provides board-level or executive sign-off capability without granting system access. Role assignments are permission chain events — tamper-evident and auditable. The separation is enforced at the API layer, not just the UI.

Yes, at two levels. PhantomKey support access is the clearest example — no standing access path exists on PhantomKey's side whatsoever. A customer Super Admin generates a single-use, time-limited support token out-of-band; without it no connection is possible regardless of any external compulsion. That path uses support tokens and Ed25519 dual-authorization — not the Hawking XOR ceremony. Break-glass key recovery is a separate mechanism: a live n-of-m Hawking ceremony where M keyholders contribute XOR components to reconstruct an access key locally. That capability stays dormant until the ceremony runs — it is not how PhantomKey support access works.

The architecture supports it through the n-of-m Hawking chain model — high-risk operations can be configured to require M-of-N keyholder authorization before execution. Passphrase rotation, break-glass access, and chain era boundaries already require explicit authorization recorded in the permission chain. Formal dual-authorization workflows for specific admin actions are a post-launch feature built on the same Hawking ceremony infrastructure already in the core.

Break-glass access in DVE uses the n-of-m Hawking chain model — emergency access requires M of N designated keyholders to contribute their XOR components simultaneously. No single person holds a complete break-glass credential. There is no standing break-glass token that can be stolen. If the primary MFA infrastructure fails, the Hawking ceremony itself is the authentication — it requires physical coordination of multiple keyholders, which is not replicable by an attacker holding a stolen token. Every break-glass ceremony is recorded on the permission chain with ceremony audit events — group_id, event type, and timestamp — confirming that the ceremony occurred and which Hawking group was involved, without recording individual keyholder identity hashes in the chain payload.

The local agent is the first line of resilience — it caches the last known valid policy state and can serve authenticated access for a configurable window without relay contact. When the relay is unreachable the agent defaults to fail-closed, which is admin-overridable to fail-open for organizations where availability outweighs the security tradeoff during an outage. Full disaster recovery restores from a chain-signed backup — the genesis block registry at PhantomKey provides provenance verification for any restored chain. Dedicated relay instances for 100+ seat organizations include enhanced availability SLAs.

Two mechanisms work in combination. For human credentials, the local agent handles all cryptographic operations on the endpoint — authentication latency is not relay-dependent and does not degrade under relay load. For machine credentials, the token model means Argon2id key derivation happens once at session establishment — subsequent high-frequency calls use the issued token, adding no derivation overhead regardless of call volume. Conditional access policy evaluation reads from locally cached permission chain state, not a live server query on every access event. Authentication performance scales with endpoint capacity, not relay concurrency.

There is no rollback because the old state is never destroyed. DVE passphrase rotation seals the old chain with a summary block and anchors the new chain to the old terminal hash — the old chain remains fully intact as a readable artifact for the duration of the rotation process. The new chain is only promoted to active status after all five chains complete rotation and validate successfully, via a single relay update. If the rotation fails at any point before promotion, the old chain is still the active chain and access continues uninterrupted. A pre-rotation backup provides an additional recovery path if needed. There is no partial state, no corrupted intermediate, and no denial-of-service risk — a failed rotation is simply a rotation that has not happened yet.

DVE maintains five append-only chains per organization — permission_chain (policy and role events), password_chain (credential content), password_audit_chain (credential access events), secret_chain (secrets content), and secret_audit_chain (secrets access and anomaly events). Administrative actions are recorded on the relevant chain: policy changes and role assignments on permission_chain; credential access events on password_audit_chain; secrets operations on secret_audit_chain. No UPDATE operations are permitted on existing blocks at the database level — append-only is an architectural constraint, not just policy. Each block embeds the current head hashes of two peer chains (the zipper model), so tampering with any block breaks the integrity of chains that reference it. The full chain history from genesis is verifiable against the PhantomKey genesis block registry.

Ephemerality applies to keys, not to records. Every access event, policy state, role assignment, and administrative action is permanently recorded in the append-only audit chain from genesis forward. The audit chain is the compliance record — deterministic, tamper-evident, and exportable as a structured signed artifact covering any date range an auditor requests. Because the active policy at every access event is embedded in the audit record, SOC 2 Type II evidence includes not just what happened but what rule governed it. The chain is verifiable against the PhantomKey genesis block registry, providing an independent provenance proof auditors can rely on.

DVE exposes a CLI for chain export, backup generation, and audit log extraction — all scriptable and schedulable without manual intervention. Exports are signed artifacts: SHA-256 manifest, genesis block signature, and chain head hashes at the moment of export, all verifiable against the PhantomKey genesis block registry. The permission chain policy ledger is exportable as a structured audit record covering every policy state from genesis to present. An API layer supports IaC integration for organizations managing DVE configuration programmatically alongside their infrastructure tooling.

A phished DVE user gives an attacker a passphrase that derives nothing without the local agent, the chain state, and the registered device — all of which the attacker doesn't have. There is no credential vault to exfiltrate because credentials don't exist at rest. The blast radius of a successful phish is bounded to what that user could access in a single authenticated session, nothing more. There is no lateral pivot from one compromised account to a database of all corporate credentials. When the incident response team revokes the user, the revocation is a permission chain event — immutable, timestamped, and immediately effective. The board report and the regulatory disclosure read very differently when the forensic record shows a contained single-session event rather than "an undetermined number of records may have been exposed."

The local agent handles credential access from the system tray — one click, no repeated authentication prompts for every application. Browser autofill is supported via a companion extension that connects to the local DVE Agent. The extension detects login forms, requests credential decryption from the agent, and fills fields without transmitting credentials through any server. At launch, the extension is available via manual installation; Web Store distribution and MDM deployment packaging are on the post-launch roadmap. Current v1 supports exact-hostname matching; multi-step login flows and iframe authentication are planned enhancements. Machine credentials rotate automatically without developer intervention. Shadow IT adoption is driven by friction — DVE's friction is at enrollment, not at daily use. An employee who sets up the agent once experiences less daily interruption than they would with MFA prompts on every application. The platform's strictness is largely invisible to the end user and highly visible to the security team.

MTD is admin-configurable, not fixed — which is itself the answer. The local agent caches the last valid policy state and continues serving authenticated access for a window the CISO sets based on the organization's risk appetite. A security-first organization might set a short window and accept fail-closed after that period. An availability-first organization sets a longer window or configures fail-open with notification. There is no global authentication failure until that policy window expires — and even then, only for new authentication attempts, not for active sessions already in progress. Organizations at 100+ seats on dedicated relay instances have enhanced availability SLAs that further extend the practical MTD.

Both, and that framing undersells it. Defensively, DVE replaces a liability — a vault-based credential system is a breach waiting to happen — with a demonstrable security posture you can put in front of enterprise procurement committees. Offensively, the audit chain is a sales asset. When your security-conscious enterprise prospect asks for SOC 2 Type II evidence, you hand them a cryptographically provable, independently verifiable record of every access event since your organization's genesis block. That is a closing argument, not just a checkbox. Organizations in regulated industries increasingly require their vendors to demonstrate security posture — DVE turns your own security investment into a procurement advantage with those clients.

The permission chain is infrastructure-agnostic — it doesn't care whether your workloads run on AWS, Azure, GCP, or a hybrid on-premises environment. The local agent runs on Windows, macOS, and Linux. SCIM and LDAP integrations normalize identity from any upstream directory. The secrets management module supports any CI/CD pipeline through standard connectors. Global scale is handled at the relay layer — dedicated instances for large deployments, and on-premises relay deployment is on the v2 roadmap for organizations with data residency or sovereignty requirements. The architecture was designed with the assumption that your infrastructure will change; the cryptographic chain that governs access does not need to be rebuilt when it does.

The published seat price is the primary cost. There are no per-API-call charges — DVE is not a consumption-billing model. Non-human service accounts are included in the org's seat count and do not carry separate licensing. Add-on modules are licensed as flat additions, not metered by usage. Implementation consulting is optional — DVE is designed for self-service onboarding with documented workflows. Organizations with complex Active Directory environments or multi-IdP federation will benefit from a structured onboarding engagement, which PhantomKey offers. Ongoing administrative training is low — the role-based UI is scoped so each role only sees what it can do. There are no surprise costs at renewal beyond the published seat tier.

Linear scaling with volume discounts — no cost cliffs. The per-seat rate decreases at published thresholds: 10, 25, 50, 100, and 250 seats, with negotiated rates above 250. Adding seats mid-contract is prorated at your current tier rate. External contractors count as seats at the same rate. Non-human service accounts are included within your existing seat count. Add-on modules are flat licensed — enabling SSO does not trigger per-user charges. The only scenario approaching a cost step is crossing a seat threshold where your per-seat rate decreases — which is a cost reduction, not a cliff.

Cyber insurers price premiums against demonstrable breach risk and incident response capability. DVE addresses both. The zero-existence architecture eliminates the credential vault as an exfiltration target — a primary driver of breach claims — which is a material risk reduction underwriters can quantify. The audit chain provides cryptographically verifiable, tamper-evident logs of every access event, policy state, and administrative action from genesis, exportable in structured formats for underwriter review. Most insurers now require evidence of MFA enforcement, privileged access controls, and audit logging — DVE satisfies all three with evidence that goes beyond policy attestation to cryptographic proof. We recommend presenting the DVE architecture and a sample audit chain export to your broker at renewal.

Migration scope depends on your current environment — a clean 1Password Business migration runs days using DVE's standard import tools. A complex Active Directory environment with custom SSO integrations and secrets across CI/CD pipelines is a larger project. DVE provides import tooling for 1Password, LastPass, Bitwarden, Dashlane, KeePass, and CSV formats. A reasonable estimate for a 50-seat organization migrating from a standard password manager with SAML SSO: two to four weeks of IT engineering time. Payback period against a single avoided breach incident is measured in days — the average enterprise breach cost in 2024 exceeded $4.5 million. Against annual platform cost, most organizations at 50 seats see full payback within the first contract year on insurance premium reduction and helpdesk overhead alone.

Meaningfully, yes. Password reset requests — typically 20–30% of Tier 1 ticket volume in enterprises — are eliminated by architecture. There is no "forgot password" flow because DVE credentials are derived, not stored and retrieved. MFA token re-enrollment, device registration, and access requests are self-service through the agent UI within admin-configured permissions. The audit chain means helpdesk staff no longer need to manually reconstruct access histories for incident investigations — the record is already there, searchable, and exportable. For a 100-seat organization, a conservative estimate of two fewer Tier 1 FTE-hours per day represents meaningful operational savings compounded across a contract year.

At v1 launch, DVE runs on Railway infrastructure with processing in the United States. Each organization's chain data is logically isolated — no cross-tenant data access is possible by architecture. Regional data residency — EU, APAC, or sovereign cloud deployments — is a v2 roadmap item delivered through dedicated relay instances in the required geographic region. Organizations with hard GDPR Article 46 transfer restrictions should plan for the v2 dedicated instance deployment. CCPA compliance is supported at v1. We recommend legal review of the DVE Data Processing Agreement before contract execution for any regulated jurisdiction.

DVE is a pre-launch product. SOC 2 Type II certification requires a minimum 6-month audit observation period and is targeted for the first full year of production operation. ISO 27001 and FedRAMP are longer-horizon targets. What DVE provides at launch that no certification can match is a cryptographically verifiable, independently provable audit record — the chain itself is the evidence. Audit chain exports are structured, signed artifacts covering any date range, exportable without manual intervention via CLI or API. An external auditor can verify the chain's integrity against the PhantomKey genesis block registry without relying on PhantomKey's own attestation. Formal certifications will be communicated to customers as they are achieved.

DVE’s operational security does not depend on any third-party decentralized ledger or external public-chain anchoring. All access control, credential storage, and authentication decisions run on PhantomKey-controlled infrastructure. Genesis blocks use CSPRNG-generated entropy as the cryptographic anchor — chosen over public-chain anchoring and zero-initialized anchors for unpredictability and zero external dependency at genesis time. Data liability for the DVE platform rests with PhantomKey Technologies under the terms of the customer Data Processing Agreement. Chain provenance is verifiable against PhantomKey’s genesis block registry without relying on any third-party network operator.

Specific SLA terms, uptime commitments, and financial remedies are defined in the DVE Enterprise Service Agreement and vary by deployment tier. Shared relay infrastructure carries a standard uptime commitment with credit-based remedies for breach. Dedicated relay instances at 100+ seats carry enhanced SLA terms. Because the local agent caches policy state and continues serving access during relay outages, a relay-side disruption does not immediately translate to an authentication failure for end users — the practical MTD substantially exceeds the relay uptime SLA window. Final SLA terms are negotiated at contract execution and reviewed by your legal team before signing.

DVE handles this with a deliberate two-layer approach. On a Right to be Forgotten request, personal identity attributes — name, email, department, device registrations — are replaced with anonymized identifiers in the active permission chain record. The audit chain historical records reference that user's identity hash rather than their personal data — the hash is not personal data under GDPR Article 4 without the mapping table, which has been anonymized. The audit record continues to show that an authenticated principal performed specific actions at specific times, satisfying regulatory audit requirements, without retaining the individual's personal data. This approach is consistent with GDPR Recital 65, which explicitly acknowledges that the right to erasure does not apply where retention is necessary for compliance with a legal obligation. We recommend your legal team review the full anonymization procedure documentation before processing any erasure requests.

Account recovery in DVE is a ceremony, not a helpdesk ticket. The workflow requires the user's manager plus one Security Admin to jointly authorize a recovery event in the permission chain — neither can do it alone. Identity verification method is admin-configurable at org level; DVE supports video verification workflows at NIST IAL2 where required, or corporate ID verification for lower-assurance environments. Once authorized, a new passphrase ceremony is initiated on a verified replacement device. The recovery event is audit-chain-recorded in full — who authorized it, what verification was performed, when, and from which device the new session was established. There is no helpdesk shortcut that bypasses the dual-authorization requirement.

The IT Admin deactivates the lost device in the fleet registry, marking it inactive — an admin dashboard action that updates fleet operational status. A temporary access state is provisioned by issuing a new device registration for a loaner machine and initiating a passphrase ceremony on that device. With pre-staged loaner hardware and a prepared IT Admin, this is a 15–30 minute process. No backdoor is created because the temporary access state is a full DVE session with the same permission chain enforcement as the executive's normal access.

Yes. The audit chain captures structured failure events with typed error codes — machine fleet status, relay unreachable, policy gate blocked (with the specific policy: fail-closed, agent mode, secret vending mode), passphrase derivation failed, chain state mismatch. The helpdesk view surfaces these as readable failure reasons scoped to the agent's role — they see enough to diagnose and route without seeing credential content. A Security Admin sees the full technical detail. The distinction between a policy block and a credential error is explicit — agents are never left guessing from generic "authentication failed" messages.

By removing the ability to reset an account via helpdesk action entirely. A tier-1 agent has no permission to authorize account recovery — that capability belongs to Security Admin plus manager dual-authorization only. No amount of social pressure on a helpdesk agent produces an account reset because the agent genuinely cannot perform one. This is enforced at the API layer, not by policy training. The panicked executive call to the helpdesk results in a ticket routed to Security Admin, who initiates the formal recovery ceremony with identity verification. The helpdesk agent is structurally protected from being the weak link.

Through the secrets management module. Each non-human identity is provisioned as a service account in the permission chain with its own identity record, access scope, and audit trail. Machine credentials are stored as secret micro-chains — self-contained, versioned, with zero-downtime rotation support. GitHub Actions, GitLab CI, Kubernetes, and generic shell/CI environments are supported via the @phantomkey/dve-connector-* packages — a set of open client libraries that pull secrets from DVE's agentless vending API using a service account credential. Each connector uses a client-side pull model: the pipeline authenticates as a service account, requests the secret value via DVE's authenticated HTTP API, and injects it into the build environment. No DVE agent installation is required on CI runners. Service accounts are first-class citizens in the permission chain — their access events appear in the secret audit chain with the same tamper-evidence as human access events.

DVE is designed to replace HashiCorp Vault and AWS Secrets Manager for organizations that want a unified credential and secrets platform. Secrets injection at launch covers: CLI export to shell environment via the dve-secret CLI, GitHub Actions and GitLab CI via the @phantomkey/dve-connector-* packages, Kubernetes via init container or sidecar pattern, and webhook-triggered pipeline re-deploys on rotation. The agentless vending API supports any runtime that can make an authenticated HTTP request — no DVE agent required on CI runners. For organizations mid-migration or with existing Vault investments, DVE can run alongside during transition. The goal is consolidation onto DVE, not immediate rip-and-replace.

No meaningful latency for high-frequency calls. Machine credential access uses a session-scoped token model — Argon2id key derivation happens once at service startup and a short-lived token is issued. Subsequent API calls authenticate against the token, not the full derivation pipeline. Token validation is a local operation with no relay round-trip on every call. Under sustained high-frequency load, DVE adds no per-call overhead beyond the token check. The derivation cost is amortized across the full token TTL, which is admin-configurable from 5 min to 24 hr.

Not on day one — honest answer. The CLI and API layer are available at launch and support scripted management of roles, groups, and access state. An official Terraform provider is on the post-launch roadmap, targeted for the first major update after launch. Organizations that require IaC on day one can script against the DVE API directly — the API surface is documented and stable. A community Terraform provider contribution path will be open from launch.

DVE exposes standard OIDC and OAuth 2.0 endpoints for application authentication — your existing backend code that speaks OIDC does not need modification. The DVE-specific cryptography is encapsulated in the agent and the relay; it is not exposed to application developers as a requirement. At v1 launch, integration is via the documented REST API — standard OIDC and OAuth 2.0 endpoints require no SDK. The @phantomkey/core SDK for programmatic access to the chain and credential layer is on the post-launch roadmap.

The DVE node service runs locally — developers spin up a local chain instance for development without a relay connection. The local instance is architecturally identical to production, so code written against the local mock behaves identically in production. Environment configuration switches between local and production relay endpoints. Offline development against a local chain instance is a supported and documented workflow, not a workaround.

Standard JWTs for application-layer authentication — your backend validates the token signature locally without a callback to the DVE relay on every request. DVE issues signed JWTs at session establishment carrying standard claims plus a DVE chain-state reference. Authorization checks against the JWT are local operations. The relay is only contacted at token issuance and expiry — not on every API call. This is the standard OAuth 2.0 bearer token model and requires no custom backend logic.

DVE is built for enterprise internal IAM, not consumer-facing CIAM. Applying DVE's full security posture to a consumer login flow would create unacceptable friction and churn — that is not the intended use case. For organizations evaluating DVE for customer identity, the honest answer is: the immovable core architecture is not calibrated for consumer UX. What DVE provides for customer-facing applications is the audit chain and compliance layer for recording customer access events, while the consumer authentication layer sits upstream. DVE governs the employees and systems who manage customer data — it is not a drop-in consumer identity platform.

Yes — custom branding is a licensed add-on module. Logo, color scheme, custom domain, and email template branding are all configurable. The end user sees your brand, not PhantomKey's. The agent UI inherits the org's branding configuration from the permission chain. White-labeling covers the web portal, email notifications, and the agent interface.

Passkeys and social login (Google/Apple SSO) are on the post-launch roadmap for the OIDC layer — not available at v1 launch. At launch, MFA method is admin-configurable between TOTP and hardware token. The architecture supports tiered authentication policies — different access levels can require different authentication strength — but consumer-grade frictionless options like magic links are outside the DVE design philosophy for the internal IAM use case. For organizations that need both consumer-grade and enterprise-grade authentication, DVE covers the enterprise layer and integrates with a consumer IdP upstream via SAML or OIDC.

DVE's architecture is specifically designed so that a vendor failure does not mean a credential failure. Your passphrase and all derived encryption keys live on your endpoints — they were never on PhantomKey's servers. Your encrypted credential envelopes can be exported at any time and are self-contained — they do not require a PhantomKey service to decrypt on your machines. The audit chain is a portable artifact: the full chain export is structured data that any organization can retain indefinitely.

In a vendor wind-down scenario: your agents continue functioning for the duration of their cached policy TTL without relay connectivity; you export your chain data and credential envelopes in full via the API; you retain all audit records independently of PhantomKey's infrastructure. There is no proprietary lock that prevents you from retaining your security history. We recommend periodic audit chain exports as part of your standard backup procedures regardless of vendor continuity planning.

DVE has undergone internal security review and penetration testing during development, including adversarial testing of the cryptographic architecture, chain integrity, and API surface. An independent third-party penetration test engagement is scheduled for the first quarter of production operation — we will share a summary of findings and remediation status with enterprise customers under NDA.

We recognize that "internal pen test" is not the same as independent assurance, and we are not asking you to take our word for it. The DVE architecture is designed so that even a successful breach of PhantomKey's infrastructure does not expose plaintext credentials — the zero-existence model is the security boundary, not the perimeter. We welcome technical briefings with your security team to walk through the architecture before contract execution. Contact security@phantomkey.pro to schedule.

PhantomKey's incident response commitment: we will notify affected customers within 72 hours of confirming a security incident that affects their organization's data, consistent with the Data Processing Agreement and GDPR Article 33 requirements where applicable.

The nature of what is at risk in a PhantomKey infrastructure incident is materially different from a traditional SaaS breach. PhantomKey's servers hold encrypted envelopes that cannot be decrypted without your passphrase-derived keys, which were never on our infrastructure. A breach of PhantomKey's backend exposes: encrypted envelopes (useless without your keys), org configuration metadata, billing records, and audit chain data. It does not expose plaintext credentials.

Incident response contact: security@phantomkey.pro. Enterprise customers may request a copy of our incident response policy during due diligence.

Self-hosted deployment is on the DVE roadmap, not available at v1 launch. At launch, DVE runs on Railway infrastructure in the United States.

For organizations with hard data sovereignty requirements that cannot be met by the current US-hosted deployment: the honest answer is that v1 DVE is not the right fit today, and we would rather tell you that now than after contract execution. The zero-existence architecture means that even in the current hosted model, PhantomKey cannot read your credentials — but if your requirement is that no metadata or audit telemetry leave your network perimeter, the hosted model does not satisfy that.

Self-hosted deployment is targeted for a major version release following SOC 2 Type II certification. Organizations with this requirement should contact us to be notified when it is available and to discuss a planned migration path from hosted to self-hosted.

DVE includes an optional in-app AI support assistant powered by Anthropic's Claude API. The assistant answers questions about DVE configuration, troubleshooting, and best practices. It is scoped to DVE-relevant queries — off-topic requests are refused by design.

What is sent to Anthropic: the text of your support question only. No credential content, no user identity data, no audit chain data, no org configuration is included in AI API calls. The assistant does not have access to your vault.

Organizations with policies prohibiting AI tool usage or with restrictions on data leaving their network can disable the AI support assistant entirely at the org level — it is an optional feature, not a core platform function. Disabling it removes Anthropic as a data sub-processor from your DPA. All other DVE functionality is unaffected.