Encryption Key Management

Overview#

Argus provides encryption key management backed by HSM hardware, automated rotation, and a multi-party recovery model, protecting data at rest with AES-256-GCM and logging every key operation for compliance and forensic use.

A single administrator with unilateral access to master encryption keys is a standing risk: one compromised account can put every customer's data in reach. Sound key management prevents exactly this, with keys generated inside hardware security modules, never exposed in software memory, and recoverable only when a quorum of geographically distributed custodians cooperate. Keys progress through a fully audited lifecycle. Organisations that must keep sole custody of the key protecting tokenised payment-card data can bring their own vault key, and secrets the platform holds on behalf of customers are envelope-encrypted at rest.

Key Features#

HSM-Protected Key Generation: All production cryptographic keys are generated within certified hardware security modules, ensuring keys are created with true random number generators and never exist unprotected in software memory.
Hierarchical Key Architecture: A multi-tier key hierarchy (master keys, key encryption keys, and data encryption keys) enables efficient key management at scale. Data encryption keys can be rotated without re-encrypting the underlying data.
Automated Key Rotation: Configurable rotation schedules automatically generate new key versions with zero-downtime transition periods. Both old and new keys remain valid during the dual-key acceptance window, ensuring continuous operations.
Cryptographic Agility: The platform supports migration between encryption algorithms without service interruption, enabling you to adopt stronger cryptographic standards as they emerge or as compliance requirements evolve.
Multi-Region Key Distribution: Key material is replicated across multiple geographic regions for high availability, with redundancy that ensures key operations continue even during regional outages.
Key Escrow and Disaster Recovery: Multi-party key custody with geographic distribution ensures cryptographic keys can be recovered in disaster scenarios while preventing any single individual from accessing key material alone.
Customer-Managed Vault Keys (BYOK): Organisations that must retain sole custody of the key protecting tokenised payment-card data generate, set, and revoke their own per-organisation vault key through self-service administration, with no platform operator involvement. There is no fallback to a shared platform key: a missing or invalid customer key fails closed, and each organisation's tokens are cryptographically isolated from every other tenant's data.
Envelope-Encrypted Held Secrets: Secrets the platform stores on behalf of customers, including webhook signing secrets and data-source connector credentials, are envelope-encrypted at rest and decrypted only at send time. Cloud API tokens held for billing and AI services are protected with dedicated derived encryption keys.
Fail-Closed Key Enforcement: The pseudonymisation vault requires its key to be present and uses a keyed reverse index, so re-identification data is never stored in a linkable form. Production startup rejects hardcoded or placeholder session secrets and enforces an entropy floor on core secrets, and national-service pseudonym keys fail closed in production rather than degrading to a predictable default.
Comprehensive Audit Trail: Every key operation is logged with full context, providing the documentation needed for compliance audits and security investigations.

How It Works#

Key Hierarchy#

Argus uses a three-tier key hierarchy to balance security with operational efficiency:

Master Key Encryption Keys (MKEK): The root of trust, protected within HSMs and never exported. Master keys protect the next tier of keys.
Key Encryption Keys (KEK): Domain or tenant-specific keys that protect data encryption keys. KEK rotation triggers re-wrapping of protected data keys without touching encrypted data.
Data Encryption Keys (DEK): Per-resource or per-file keys used for actual data encryption with AES-256-GCM. DEK rotation is efficient because only the key wrapping changes, not the encrypted data.

Key Lifecycle#

Keys progress through a managed lifecycle:

Pre-Active: Generated but not yet activated for production use
Active: Currently valid for all cryptographic operations
Rotating: In transition, with both old and new versions accepting operations
Deprecated: Old version after rotation, limited to decryption only
Deactivated: Manually disabled but recoverable
Destroyed: Securely wiped and irrecoverable

Key Rotation#

The platform supports three rotation strategies:

Scheduled Rotation: Automatic rotation on configurable schedules with proactive notifications and dual-key acceptance periods
Event-Triggered Rotation: Immediate rotation in response to security incidents, suspected compromise, or regulatory changes
On-Demand Rotation: Administrator-initiated rotation for emergencies, with multi-party approval for production keys

Customer-Managed Keys#

For data where the organisation itself must hold the key, such as tokenised payment-card material, key custody moves from the platform to the customer:

Organisation administrators generate, set, and revoke the vault key through self-service administration; no platform operator is involved
Key status reporting exposes a fingerprint only, so key material is never displayed or returned
Protection policy flag updates merge safely, so enabling one protection never wipes another
Customer-managed keys rotate independently of platform-managed keys, on the organisation's own schedule
A one-generation rotation recovery path preserves access to existing tokens during rotation, with preserve-or-abort semantics so tokens are never orphaned silently

Disaster Recovery#

Key recovery is protected by a multi-party custodian model:

Designated key custodians are geographically distributed
A quorum of custodians is required for key recovery operations
Hardware security tokens provide secure share storage
Regular recovery drills validate procedures
Recovery capabilities range from automatic failover for component failures to custodian-assisted recovery for catastrophic events

Open Standards#

NIST FIPS 197 / AES-256-GCM: All data encryption keys and protected fields use AES-256-GCM as the symmetric cipher, with 96-bit random nonces and GCM authentication tags binding ciphertext to per-row Additional Authenticated Data.
PKCS#11 (OASIS): Hardware Security Module integration uses the PKCS#11 API to generate, store, wrap, and unwrap key material; the master Key Encryption Key is held non-extractable inside the token using CKM_AES_KEY_WRAP.
NIST SP 800-38D: The GCM mode of operation is applied in strict conformance with SP 800-38D, including the 96-bit nonce recommendation and per-ciphertext authentication tag verification.
NIST FIPS 203 (ML-KEM-768): The optional post-quantum layer wraps Data Encryption Keys using the ML-KEM-768 Key Encapsulation Mechanism (standardised from Kyber-768) in a hybrid ECDH-P256 + ML-KEM scheme per NIST SP 800-227.
NIST FIPS 204 (ML-DSA-65): Post-quantum digital signatures use ML-DSA-65 (standardised from Dilithium-3) combined with ECDSA-P256 for hybrid signing, ensuring cryptographic agility against future quantum threats.
NIST FIPS 140-2: The HSM integration and overall encryption design target FIPS 140-2 compliance, requiring certified hardware for key generation and enforcing that raw key material never leaves the HSM in plaintext.

Compliance#

Encryption key management supports compliance with:

PCI-DSS: Cryptographic key management requirements for cardholder data protection
HIPAA: Encryption requirements for protected health information
SOC 2: Cryptographic controls for data confidentiality
SOX: Data protection controls for financial information
GDPR: Technical measures for personal data protection
FedRAMP: Cryptographic requirements for government data

Last Reviewed: 2026-07-16 Last Updated: 2026-07-16

Encryption Key Management

Ready to Build?