PLATFORM SECURITY ARCHITECTURE
Every connection proves itself.
Epiphron DRTx® moves your firm's most sensitive operational data across a mutually authenticated, certificate‑bound fabric: a private PKI that runs itself, non‑exportable key custody, and a cryptographically signed root of trust. On your premises, under your policy.
TLS 1.2/1.3 only
mutual TLS everywhere
ECDSA P-256 licensing
RSA-2048+ private PKI
BCrypt credential hashing
CSPRNG session tokens
ONE SECURITY FABRIC
Trust flows from one signed source
The customer license — signed in Azure Key Vault, verified on every load — carries the CA trust anchors and the security policy for the whole deployment. Every channel between every peer then demands proof in both directions. No local configuration file can weaken the transport or identity layers.
Signed customer license ECDSA P-256 · signed in Azure Key Vault CA trust anchors security policy · enrollment provider Trading workstation CN=EpiphronClient.<user> Excel & integration clients per-user client certificates Automation & services non-exportable private keys mTLS operations · live push telemetry · enrollment DRTx® service host CN=EpiphronService per-call token check certificate ↔ user binding rights evaluated, fail-closed SQL Server encrypted connection, fail-closed RIA service accepts only the core service's cert Azure Key Vault / your AD CS CA keys never touch the host mTLS certificate issuance Trust anchors travel inside the signed license — nothing is ever written to a Windows trust store, and no public CA is trusted for peer identity.
Swipe to explore the diagram →
Three decisions that shape everything
Identity-bound transport
Both ends of every connection present certificates from your private CA — checked for exact identity, key usage, and issuer. Then every single call re-proves itself: a CSPRNG session token in the message, and the caller's certificate matched to the session's user. A stolen token is useless from anyone else's channel.
A PKI that runs itself
Per-user certificates enroll automatically at first login: the private key is generated on the user's machine and never travels, the request is password-gated and proof-of-possession checked, and the issued certificate installs non-exportable. Renewal happens before expiry, over the authenticated channel. Signing runs in Azure Key Vault — or against your own Microsoft AD CS.
A root of trust you can hold
Your deployment's security posture is set by a license signed with ECDSA P-256, its signing key held in Azure Key Vault where it can be neither read nor copied. The license carries your CA anchors and your security policy — so no local config edit, on any machine, can quietly downgrade the deployment.
DEFENSE IN DEPTH
Six gates between the wire and your data
1 TLS 1.2 / 1.3 protocol floor, pinned 2 Mutual certificates identity + key usage + issuer pin 3 Session token 32-byte CSPRNG, every call 4 Certificate ↔ user matches the session user 5 Granted rights 60+ rights, fail-closed 6 Audit who, what, from where — always
1
TLS 1.2 / 1.3
protocol floor, pinned
2
Mutual certificates
identity + key usage + issuer pin
3
Session token
32-byte CSPRNG, every call
4
Certificate ↔ user
matches the session user
5
Granted rights
60+ rights, fail-closed
6
Audit
who, what, from where — always
Authorization that fails closed
A valid certificate and a live session prove who is calling — they grant nothing. Permissions resolve through users, groups, roles, and business units into more than sixty discrete rights, each grantable as view, add, edit, delete, or execute. Security administration itself is decomposed, so separation of duties is something you configure, not something you hope for. Any error while evaluating a right denies it.
Per-user, per-group, and per-business-unit data limits
Interactive and batch identities are distinct login types
Live session monitoring with administrative termination
Evidence by default
Every login attempt — successful or not — is recorded with source IP, machine, OS user, and client application. Every configuration change is audited field by field, old value and new. Security events land in the service log and the Windows event log with the context an analyst actually needs: which certificate, which endpoint, which user, from where.
Session forensics queryable by user and date range
Field-level change trail with full actor attribution
Handshake rejections and token failures logged with source
ON-PREMISES, BY DESIGN
Your servers. Your firewall. Your policy.
Services run as least-privilege accounts — rights are granted by the installer, not by “run as admin”
Security events land in the Windows event log, ready for your SIEM collectors
Clients connect only to the endpoints you publish — users supply credentials, nothing else
Database connections run encrypted — the service refuses to start otherwise
A compact, documented port surface your firewall team gets in one table
Air-gapped and ceremony-driven CA workflows supported alongside automatic enrollment
Put your security team in front of ours.
The complete Platform Security Reference — port matrix, PKI design, enrollment flows, audit schema — is available to evaluating firms under NDA.
Request A Security Briefing