Multi-factor
The factor your users actually carry
Biometric, hardware token, TOTP, SMS-based two-factor and email one-time codes are all supported, so the second factor can match the hardware your people already have.
Assume the perimeter is already gone. Encrypt and verify anyway.
OmniPriv is built on the assumption that something will eventually end up somewhere it should not. Every secret is encrypted, every component talks over mutual TLS, and every login can be made to prove more than a password.
Multi-factor authentication is enforced up front, a layered key hierarchy protects what is stored, and cryptographic hash-chaining protects what is recorded, so integrity holds even when the storage layer underneath is not trusted.
Security layers · one secret, end to end
- Verify
- Encrypt
- Transmit
- Record
Login proves more than a password
- Password
- Hardware token
- Keystroke rhythm on baseline
Encrypted at rest, in transit and between componentsillustrative
- key hierarchy: KEK, DEK and SEK
- 3-tierkey hierarchy: KEK, DEK and SEK
- second-factor methods, from biometrics to email codes
- 5second-factor methods, from biometrics to email codes
- audit rows per HMAC-SHA256 checkpoint, verified every 5 minutes
- 50audit rows per HMAC-SHA256 checkpoint, verified every 5 minutes
- hard-coded credentials inside the platform
- 0hard-coded credentials inside the platform
Verification before authorization
Identity is checked continuously rather than once. Nothing in the platform treats a successful login as proof of anything that happens afterwards.
Keystroke dynamics
Adaptive MFA at login
Keystroke rhythm, speed and pattern are compared against the identity's learned baseline. A drift triggers an MFA challenge automatically rather than being logged and ignored.
Role boundaries
Isolation between administrators
An administrator cannot reach credentials or approve requests outside their defined role boundaries, enforced at every access layer, not only in the interface.
Encrypted at rest, in transit, and between components
Encryption only means something if it covers the whole path. Stored credentials, data in flight, and the internal traffic between OmniPriv's own components are each encrypted separately, so no single layer is the only thing standing between an attacker and a secret.
- A layered key hierarchy (KEK, DEK, SEK) protects stored keys
- Envelope encryption covering data at rest and in transit
- Mutual authentication between platform components, so nothing crosses the wire in plaintext at any layer
Encryption coverage · whole pathNo plaintext layer
- UserIn transit · TLS
- GatewayBetween components · mutual TLS
- VaultKEK · DEK · SEKAt rest · envelope encryption
- Storagebackups encrypted too
Integrity and key custody
The harder question is not whether data is encrypted, but who holds the keys and whether anyone could change the record afterwards.
Tamper-proof audit storage
Audit records are held in tamper-proof storage with cryptographic audit-chain hashing, preserving integrity and non-repudiation, not merely retaining entries.
Zero hard-coded credentials
The platform itself contains no hard-coded credentials. Every secret it uses is vault-managed and auditable, including the ones that keep the platform running.
Independent key backup
The installation key is generated at installation and must be stored externally and independently of the platform, then carried forward across upgrades and migrations.
Encrypted backups
Backups are fully encrypted with independent, secure key management, so a stolen backup is not a stolen credential store.
Audit trail · hash-chainedillustrative
- #1043prev fdcd5272 · hash 9c04cc23
- #1044prev 9c04cc23 · hash 3a3c45d4
- #1045prev 3a3c45d4 · hash d873bf85
- #1046prev d873bf85 · hash 76ab3936
HMAC-SHA256 checkpoint every 50 rows, chain verified every 5 minutes
Installation key held outside the platform
Put the encryption where the risk actually is
- Encrypted in transit
- Encrypted at rest
- Hash-chained throughout
MFA at the front, layered keys behind it, mutual authentication between every component and hash-chained records underneath.
We will walk through the encryption model and the key custody arrangements against your environment.
Frequently Asked Questions
Have a question that is not here?
Talk to the OmniPriv team about your identities, systems and AI agents.
Request a DemoBiometric factors, hardware tokens, TOTP authenticator apps, SMS-based two-factor and email one-time codes. Supporting several matters in practice, because a second factor only helps if the people who need it are willing and able to use it.
Keystroke dynamics are the rhythm, speed and pattern of how a person types. OmniPriv compares those characteristics against the identity's learned baseline at login, and a meaningful deviation triggers an MFA challenge automatically rather than being recorded and left alone.
Sensitive data is encrypted both at rest and in transit, with a layered key hierarchy (KEK, DEK, SEK) protecting the keys. Traffic between the platform's own components is mutually authenticated and encrypted, so there is no plaintext layer inside the stack.
It is the key generated when the platform is installed, and it must be stored externally and independently of OmniPriv itself. Keeping it separate is what stops a compromise of the platform's storage from also handing over the means to decrypt what is in it, and it has to be carried forward across upgrades and migrations.
No. OmniPriv contains zero hard-coded credentials, every secret it uses is vault-managed and auditable. That is a deliberate design constraint rather than a configuration option, because a hard-coded credential is one that no rotation policy can ever reach.
