Architecture

Distributed by design. Secure by mathematics.

A centralized secret store where all credentials, keys, and sensitive configuration live under a single trust boundary. Every service authenticates against the same backend and receives secrets from one root of trust.

Encryption typically relies on a single master key or a small hierarchy derived from one root. Access control is enforced at the policy layer, but the underlying cryptographic domain is shared — meaning all sealed data can be unlocked by the same key material.

If the master key or root token is compromised, every secret in the system is exposed simultaneously. There is no cryptographic isolation between tenants, environments, or secret classes — only logical separation via ACL policies.

Keyra, a domain-isolated vault system where each vault operates as an independent cryptographic boundary. Every vault has its own root key, encryption context, and trust chain — completely separate from its peers.

Secrets are sealed within their respective domains using independent key hierarchies. There is no shared master key that can unlock multiple vaults. Cross-domain access requires explicit, auditable delegation rather than implicit trust inheritance.

A breach of Vault A exposes only Vault A's secrets. Vaults B and C remain cryptographically sealed — their key material is entirely separate. This limits blast radius and eliminates single-point-of-failure trust collapse across the system.

Cryptographic trust model - Built on Kerckhoffs's Principle, not blind trust

Kerckhoffs’s principle states that systems must remain secure even if everything about the system is known except the key.

Keyra applies this principle to enterprise secrets management:

Vault structure is not a secret
Server location is not a secret
Infrastructure compromise does not expose secrets
Only cryptographic keys grant access

This eliminates reliance on infrastructure secrecy.

Blast Radius Intelligence

DevOps and platform engineering

Built for automation, not manual vault management Includes:

CLI tool
SDK
Secret migration from KeePass and other vaults
Git repository for ciphertext domains
Fully scriptable vault operations

Traditional PAM vs Fat Vaults vs Keyra

Traditional PAM systems

Traditional PAM systems centralize secrets into a single vault protected by infrastructure controls and master keys.

While powerful, they introduce:

single catastrophic trust point
high operational complexity
heavy infrastructure requirements
difficult lifecycle enforcement

If compromised, attackers gain broad access.

Fat vault applications

Fat vaults store secrets in a single encrypted file.

While encryption is strong, operational security is weak:

vault file often copied across systems
no secure collaboration model
no identity integration
no lifecycle automation
no blast radius awareness
no DevOps integration

Security depends entirely on protecting the vault file.

Once copied, secrets can be attacked offline indefinitely.

This creates invisible and uncontrolled secret sprawl.

Keyra distributed vault architecture

Keyra eliminates both centralized vault risk and fat vault limitations.

Keyra provides:

distributed cryptographic trust domains
no single vault file containing all secrets
secure collaboration with cryptographic isolation
full DevOps and automation support
identity-aware access control
blast radius intelligence

Compromise of one vault domain does not compromise others.

Authentication and Cryptographic Key Protection

Flexible authentication across independent trust domains

Keyra supports multiple authentication and key protection mechanisms, allowing access to be configured for individual users, teams, and enterprise environments without compromising the cryptographic isolation of individual vaults.

Active Directory and enterprise identities

Integration with Active Directory enables identity-based access management for multiple users and groups. Enterprise identities support collaboration and controlled access across organisational boundaries.

Multiple YubiKeys with Challenge–Response

Keyra supports multiple YubiKey hardware security keys using cryptographic Challenge–Response. Hardware-generated responses provide an additional means of protecting cryptographic key material without relying exclusively on passwords.

Multiple passwords

Multiple password-based authenticators are supported, enabling flexible credential configurations and protection strategies.

Platform-dependent hardware authenticators

Keyra supports additional hardware-backed authenticators depending on the operating system and available platform capabilities. These complement password-based protection and YubiKey Challenge–Response without requiring a specific authentication technology.

Separation of identity, authentication, and cryptographic trust

Keyra distinguishes between identity management, authentication, and cryptographic key protection. Access policies determine who is authorised, while cryptographic mechanisms protect the underlying vault secrets.

Each vault remains an independent cryptographic trust domain with its own key material and protection context. Authentication flexibility does not introduce a shared master key across vaults.

Protection Against Source-Level Attacks and AI-Assisted Reverse Engineering

Compiled Rust Core

Keyra's security-critical core is developed in Rust and compiled into native machine code. The proprietary source code is not included in distributed software packages.

This denies attackers direct access to one of the most valuable sources of information for targeted software exploitation: the original implementation.

Without source code access, attackers cannot directly inspect the Rust implementation, its dependencies, cryptographic parameter configurations, internal control flows, or potential implementation vulnerabilities at source level.

AI-assisted analysis tools are equally denied direct access to the original codebase. Investigating the implementation instead requires more demanding binary analysis, runtime examination, and reconstruction of relevant execution paths.

This significantly increases the technical effort, time, and uncertainty involved in targeting Keyra's proprietary implementation.

Protected Development Infrastructure

Keyra's complete proprietary source code is maintained on specially secured servers within a controlled on-premises infrastructure.

Private cryptographic keys used for software package signing are likewise managed within the protected on-premises infrastructure.

The separation between the protected development environment and distributed binaries prevents direct exposure of the original implementation through software distribution.

Cryptographically signed software packages additionally enable verification of their origin and integrity.

Multiple Independent Layers of Protection

Keyra combines cryptographic isolation across independent trust domains with protection of its proprietary implementation and a controlled software supply chain.

Keeping the source code inaccessible removes opportunities for direct source-level inspection and makes targeted identification of implementation weaknesses more difficult.

Together, these measures establish an additional, deliberately engineered layer of protection against source-level attacks and AI-assisted analysis techniques.