diff --git a/docs/functionalities/14072026-krypton.md b/docs/functionalities/14072026-krypton.md
new file mode 100644
index 0000000..8c059f6
--- /dev/null
+++ b/docs/functionalities/14072026-krypton.md
@@ -0,0 +1,208 @@
+# Krypton — Capabilities Reference
+
+This document describes capabilities of Krypton Ecosystem as a whole. For each capability it answers: what it does, why we need it.
+
+**DISCLAIMER**: Krypton Ecosystem will consist of different components/artifacts as Control Plane/Central Authority,
+many Agents (for Regional and Edge deployment), Admin CLI and at some point in time Krypton Web as Viewer UI!
+Bellow related capabilities are for different Krypton components from the whole it's Ecosystem.
+
+---
+
+## 1. Infrastructure & Storage
+
+*The foundation: how Krypton stores data reliably and runs across multiple machines.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 1 | **PostgreSQL storage with row-level security** | All keys, audit records, and operational events live in a PostgreSQL database. Each row is automatically tagged with the tenant it belongs to, and the database itself enforces that one customer's data is invisible to every other customer — even if there is a bug in application code. Without this, a single software defect could expose one customer's keys to another. |
+| 2 | **Automated schema migrations** | When Krypton is upgraded, it updates the database structure automatically before any traffic is served. A distributed lock ensures the migration runs exactly once, even when many instances start simultaneously. Without this, upgrading a multi-node cluster would require manual database changes coordinated across all nodes, creating a dangerous gap where old and new software disagree on the schema. |
+| 3 | **Distributed leader election** | Multiple Krypton nodes run simultaneously for high availability. A distributed advisory lock mechanism ensures that exactly one node runs each scheduled background job at any given time, preventing duplicate key rotations, duplicate garbage-collection passes, or duplicate audit writes. Without this, running multiple nodes would cause the same rotation to fire on every node at once, producing conflicting key versions. |
+| 4 | **Plugin architecture** | External integrations — cloud KMS providers, hardware security modules, storage backends, notification channels — are loaded from configuration at startup, not compiled into the binary. Organisations can add a new cloud provider or swap out a notification channel without touching Krypton's core code. Without this, every new integration would require a software release and deployment cycle. |
+| 5 | **OpenTelemetry observability** | Every component emits traces, metrics, and structured logs in the OpenTelemetry standard format. These can be forwarded to Grafana, Datadog, Jaeger, Prometheus, or any compatible observability platform. Without this, diagnosing latency spikes, tracing a failed decrypt across distributed nodes, or alerting on error-rate changes requires building custom instrumentation from scratch. |
+
+---
+
+## 2. Cryptographic Engine
+
+*The math: what kinds of encryption, signing, and key derivation Krypton can perform.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 6 | **Symmetric encryption** | Encrypts data using a shared secret key. AES-256-GCM is the primary algorithm — it encrypts and authenticates simultaneously, so tampering with the ciphertext is detected automatically. AES-GCM-SIV (RFC 8452) provides nonce-misuse resistance for use cases where the same plaintext must always produce the same ciphertext, such as privacy-preserving financial-crime detection. ChaCha20-Poly1305 is available for environments where hardware AES acceleration is absent. AES-CBC is retained strictly for decrypting legacy data — creating new keys with AES-CBC is blocked. Without strong authenticated encryption, an attacker who modifies ciphertext in transit or storage would not be detected. |
+| 7 | **Asymmetric (public-key) cryptography** | Uses a key pair — a public key for verification or encryption, a private key that only Krypton holds. Supports RSA, ECDSA over NIST P-256/P-384/P-521, Ed25519, Ed448, X25519, and ECIES. RSA signature verification uses only PSS padding — the older PKCS#1 v1.5 padding is not accepted. X25519 key exchange rejects low-order input points that could force a weak shared secret regardless of private key quality. Without these controls, an attacker could forge signatures or force a predictable encryption key in an X25519 exchange. |
+| 12 | **HKDF key derivation (NIST SP 800-108)** | When a key is derived from another key, the derivation binds both the intended algorithm and the output length into the derivation input. This prevents key confusion: it is impossible to accidentally use the same master key to derive two keys intended for different purposes or different sizes and get the same result. Without this binding, a key derived for HMAC could collide with a key derived for AES if both happen to request 256 bits from the same parent. |
+| 13 | **Shamir's Secret Sharing (cryptographic primitive)** | Splits a secret into N shares such that any M shares can reconstruct it, while possessing fewer than M shares reveals nothing about the secret. Invalid share coordinates are rejected during reconstruction to prevent a corrupted share from producing a plausible-but-wrong master key that passes basic sanity checks before failing on actual use. This is the foundational primitive for the multi-custodian unsealing ceremony. |
+| 14 | **Secure memory handling** | Key material is stored in memory regions that the operating system is instructed never to swap to disk. The moment key material is no longer needed — whether because a key was deleted, revoked, or the operation completed — the memory is overwritten with zeros. This means a core dump, swap file, memory snapshot, or cold-boot attack cannot reveal key bytes that have already been used and discarded. Without this, sensitive key material could persist in system memory or on disk long after it is logically deleted. |
+
+---
+
+## 3. Key Hierarchy & Wrapping
+
+*How keys protect each other: the chain of trust from master key down to data keys.*
+
+Krypton organises keys in layers. Each layer's key is encrypted ("wrapped") by the key in the layer above it. To use any key, you must first unwrap it using its parent, which requires unwrapping that parent, and so on up to the master key. This structure means:
+
+- Compromising one data key does not expose any other keys at the same or higher level.
+- Rotating a parent key automatically re-protects every key it wraps.
+- The master key never touches disk — it exists only in protected memory after unsealing.
+
+| # | Capability | What it means |
+|---|---|---|
+| 15 | **Master key (L0)** | The root of the entire trust hierarchy. It never leaves protected memory and is never written to disk. Every other key in the system is ultimately protected by this key — directly or through a chain of wrapped intermediate keys. Without the master key present (i.e. when Krypton is sealed), no cryptographic operation is possible. |
+| 16 | **Internal versioned key (IVK)** | A domain-scoped key that sits directly above user-facing tiers in the hierarchy. It provides an extra wrapping layer between application keys and the external cloud KMS. If the cloud KMS is compromised, the attacker still cannot read application data because the IVK adds a layer of protection that lives entirely within Krypton's trust boundary. Without the IVK, a cloud KMS breach would directly expose application keys. |
+| 17 | **External root key (L1 / ExternalRoot)** | Delegates the outermost wrapping to a third-party KMS or HSM (AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault, or PKCS#11 HSM). The external provider wraps the key material; Krypton controls every inner layer. Neither Krypton alone nor the cloud provider alone can read your data — both must cooperate. This satisfies BYOK (Bring Your Own Key) and HYOK (Hold Your Own Key) requirements for regulated industries. |
+| 18 | **Domain key (L2)** | A key scoped to a single tenant or business domain, grouping all of that domain's service keys. Changing or revoking a domain key affects only that domain's data, not any other tenant's. It is wrapped by both the IVK and the ExternalRoot, so two independent wrapping layers must be penetrated to access it. |
+| 19 | **Service key (L3)** | A key scoped to a single service within a domain (for example, the payments service or the messaging service). Rotating a service key affects only that service's data encryption keys, not other services in the same domain. This containment limits the blast radius of any key compromise. |
+| 20 | **Data key (L4)** | The leaf key used directly to encrypt application data. It is the key your application uses to encrypt a record, a file, or a message. All higher layers exist to protect this key — the actual data never leaves your application; only the data key transits to Krypton for wrapping. On edge deployments, the data key is wrapped by the remote central authority, so edge nodes hold only the leaf material, not the full chain. |
+| 21 | **Cascade wrapping** | Each tier wraps the tier below it in sequence, like nested envelopes. When decrypting, each layer is opened in reverse order and the intermediate plaintext from each step is erased as soon as the next step completes. This means a partial decryption attempt that fails partway through cannot leave usable plaintext in memory. |
+| 22 | **Self-describing wrapping blobs** | Every stored key blob contains a complete record of which keys wrapped it and in what order. This means you can inspect any stored blob offline — without querying the database — to trace the full wrapping chain. It also means forged or truncated blobs are rejected: trailing bytes after the expected payload boundary are treated as tampering. |
+| 23 | **Key material integrity verification** | Every key blob is signed with an authentication code when written to the database. Before a blob is loaded into memory, that code is verified. A database attacker who can write rows cannot silently substitute a malicious key — the verification detects the substitution and rejects the blob. The error message from a failed verification does not reveal what the correct code should be, preventing the database write access from being used as an oracle. |
+
+---
+
+## 4. Key Lifecycle
+
+*How keys are born, age, and die.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 24 | **Key lifecycle state machine** | Every key version moves through a defined sequence of states: pre-activation, active, suspended, deactivated, compromised, pending-destruction, destroyed. The system enforces that transitions follow only the allowed paths — for example, a destroyed key can never be reactivated, and a deactivated key cannot skip directly to active. This follows NIST SP 800-57 Part 1 guidance on key state management. Without enforced state transitions, an operator could accidentally reactivate a key that was retired for security reasons. |
+| 25 | **Mandatory key metadata (NIST SP 800-57)** | Every key version automatically records: the cryptographic algorithm, the key bit-length, the exact moment it became active (the start of its cryptoperiod), and how it was created (generated by Krypton, imported, or derived from another key). These are the attributes required by NIST SP 800-57 Part 1 §5.3.1. Without this metadata, auditors cannot verify that keys met minimum length requirements, that they were not used past their cryptoperiod, or that the origin of key material is known. |
+| 26 | **Cryptoperiod enforcement** | Each key tier has a configured maximum age. Once a key exceeds that age, it is refused for new encryption and signing operations immediately — it does not wait for the next scheduled cleanup sweep. If the cleanup job is delayed or skipped, expired keys are still blocked. Configuring a zero maximum age is rejected at startup, preventing accidental perpetual keys. Without fail-closed cryptoperiod enforcement, a key could continue encrypting new data indefinitely after its permitted usage window has passed. |
+| 27 | **Key usage restriction** | Each key carries a declaration of what operations it is permitted to perform: encrypt, decrypt, sign, verify, wrap other keys, export, and so on. An attempt to use a key for an operation it was not created for is rejected, regardless of who is making the request. Without this, a signing key could be misused for encryption, mixing cryptographic purposes in a way that weakens both. |
+| 28 | **Automatic key rotation** | When a key reaches its rotation interval, a new version is created, the old version is marked deactivated, and all new operations switch to the new version — all without operator intervention. The transition is atomic in the sense that there is no window where both old and new versions appear active at the same time. Rotation events are durably recorded so they survive process restarts and can be replayed for audit. Without automatic rotation, cryptoperiod limits would require constant manual intervention or would simply be ignored in practice. |
+| 29 | **Cascading re-wrap after rotation** | When a parent key is rotated, every child key that was wrapped by the old parent version is automatically re-encrypted under the new parent. The old parent's key material is cleared from memory immediately after all its children have been re-wrapped, so the old material has the shortest possible lifetime. Without this, rotating a parent key would leave all its children still protected only by the old parent — the rotation would provide no actual security benefit. |
+| 30 | **Key garbage collection** | Keys that have been destroyed and have passed their mandatory retention period are permanently and irrecoverably deleted. The deletion is ordered so that a key is marked logically destroyed in metadata before its physical material is removed. If the process crashes between those two steps, the key is already treated as dead and any orphaned physical material is cleaned up on the next sweep. Without ordered deletion, a crash mid-delete could leave a key in an ambiguous state — neither alive nor fully gone. |
+| 31 | **Scheduled state transitions** | A key state change (for example, deactivating a key at a specific date, or destroying it after a retention period expires) can be scheduled in advance. The system applies the transition automatically at the configured time, with no operator action required at that moment. Without scheduled transitions, compliance deadlines for key retirement would require calendar reminders and manual operations, which are prone to being skipped under operational pressure. |
+
+---
+
+## 5. Access Control & Security Enforcement
+
+*Who is allowed to do what, and how Krypton enforces it.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 32 | **Sealed-by-default** | Krypton refuses all cryptographic operations from the moment it starts until the master key has been assembled from custodian shards. There is no override or bypass for this state — no emergency mode that allows operations before unsealing is complete. Every seal and unseal event is written to the audit log with the identity of whoever triggered it, the timestamp, and the outcome. Without this, a newly started Krypton instance could process requests before its key hierarchy is fully established. |
+| 33 | **Multi-layer authorization chain** | Every request passes through up to twelve independent authorization checks in sequence: token revocation status, request velocity limits, per-IP rate limiting, an allow-list check, bot and anomaly detection, multi-custodian quorum requirements, tenant isolation enforcement, fine-grained policy (OpenFGA), attribute-based policy (Cedar), and RBAC role checks. If any layer is misconfigured in a way that produces an ambiguous result, the request is denied rather than allowed. Without layered authorization, a bypass of any single check would grant full access. |
+| 34 | **Tenant isolation** | Each tenant's keys, operations, events, and policies are invisible to every other tenant — enforced simultaneously at the application layer and at the database layer using row-level security. Even if application code has a bug that constructs a query without a tenant filter, the database will still refuse to return another tenant's rows. Without dual-layer isolation, a single application bug could expose one customer's keys to another. |
+| 35 | **M-of-N quorum approval** | High-sensitivity operations can be configured to require approval from M out of N designated custodians before they execute. No single individual — not even an administrator — can authorize these operations alone. This is the technical enforcement of dual-control and split-knowledge principles required by PCI-DSS and other standards. Without quorum, a single compromised administrator account could authorize irreversible key destruction or emergency revocation without checks. |
+| 36 | **Key usage enforcement** | Every key carries a declaration of what it may be used for. A key created for signing cannot be used for encryption, a key without the export flag cannot be extracted, and a key without the wrap flag cannot wrap other keys — regardless of the requester's identity or role. Without usage enforcement, a key created for a narrow purpose could be misused in ways that violate the security assumptions it was designed under. |
+| 37 | **Durable audit trail** | Every operation on every key — creation, rotation, access, failure, and revocation — is appended to a tamper-evident, durable ledger. Each record automatically carries the required fields for PCI-DSS v4 Req 10.3.1: a UTC timestamp, the identity of the actor, the type of actor (human, service, or system), the source IP address, and the outcome (success or failure). Without this, a security incident investigation cannot determine who accessed what key, when, and from where. |
+| 38 | **Instant token revocation** | When an authentication token is revoked — for example, because an employee leaves or a credential is suspected compromised — any subsequent request using that token is rejected at the gateway before it reaches any business logic. There is no delay or eventual consistency — revocation is effective immediately. Without this, a stolen token would remain valid until its natural expiry, potentially for hours or days. |
+| 39 | **Mutual TLS between nodes** | Communication between Krypton nodes uses mutual TLS, meaning both sides of every connection must present and verify a certificate. A node without a valid certificate cannot join the cluster or receive key material. Without mutual authentication, an attacker who gained network access could impersonate a legitimate node and intercept or inject key operations. |
+| 40 | **Replay attack prevention** | Every request carries a timestamp. Requests with timestamps that fall outside the allowed freshness window are rejected. Without this, an attacker who captured a legitimate signed request could re-submit it minutes or hours later to trigger the same operation again — for example, replaying a key deletion. |
+| 41 | **Client-side credential encryption** | Sensitive values — cloud API keys, database passwords, HSM PINs — that operators submit as part of plugin configurations are encrypted on the operator's machine before they are sent to Krypton. The encryption uses Krypton's public key, so only Krypton's server can decrypt them. The corresponding private key never leaves the server and is never transmitted over any API. Without this, sensitive credentials would appear in plaintext in API requests, where they could be captured by proxies, logs, or network monitoring. |
+
+---
+
+## 6. Sealing & Unsealing
+
+*How Krypton protects and reconstructs its master keys at startup and during emergencies.*
+
+### What "sealing" means
+
+Krypton holds three master keys in protected memory. On every start, those keys are absent — Krypton is **sealed** and refuses all cryptographic requests until the keys are present. **Unsealing** is the process of fetching the secret material needed to reconstruct each master key and loading the result into protected memory. Until unsealing is complete, the server is a locked safe with no combination entered. Sealing Krypton again (locking it) erases all master key material from memory, immediately halting all cryptographic operations.
+
+### The three master keys — why three?
+
+Krypton separates master key material into three distinct keys, each with one precisely defined purpose. This separation means that a breach of one capability does not automatically compromise the others — an attacker who steals the credential-encryption key cannot read application data, and an attacker who compromises the signing key cannot decrypt any keys or credentials.
+
+| Key | Algorithm | Purpose |
+|---|---|---|
+| **MasterKey** | AES-256-GCM | The sole purpose of MasterKey is to wrap (encrypt) all keys below it in the hierarchy — IVK, domain, service, and data keys. It performs no other function: it does not sign, it does not encrypt credentials, and it is not used to derive other keys. Every other key in the system is ultimately protected by MasterKey, which is why its ceremony is the most sensitive operational procedure. Compromising MasterKey does not expose application data directly — an attacker would still need to unwrap every individual child key — but it means the entire key hierarchy must be re-wrapped under a new ceremony as a precaution. |
+| **MasterCryptoKey** | AES-256-GCM + X25519 | The sole purpose of MasterCryptoKey is encrypting Krypton's own internal secrets: the cloud provider API keys, database passwords, and HSM PINs that operators submit when configuring external integrations. These secrets are stored in the database in encrypted form; MasterCryptoKey is required to read them. MasterCryptoKey also provides the asymmetric key pair that operators use when submitting new secrets to Krypton from the command line — the operator encrypts with the public key, and only Krypton's server holds the private key needed to decrypt. Separating this from MasterKey ensures that a breach of the credential store cannot be used to read the key hierarchy, and vice versa. |
+| **MasterSigningKey** | HMAC-SHA-256 (default), Ed25519, or ML-DSA | The sole purpose of MasterSigningKey is signing every key blob written to the database and verifying that signature on every read. Because every stored key carries a cryptographic signature, an attacker who gains write access to the database cannot silently substitute a malicious key — the signature mismatch will be detected before the key is ever used. Separating this from MasterKey means that signing authority can be held by a different group of custodians than wrapping authority, enabling organisations to enforce independent oversight of who can write to the key store versus who can operate the wrapping hierarchy. |
+
+When not given an independent ceremony, MasterCryptoKey and MasterSigningKey are derived from MasterKey using separate, domain-isolated derivation inputs. A single Shamir ceremony then covers all three. Independent ceremonies are for organisations that require separate custodian groups for signing and wrapping authority.
+
+### The three seal mechanisms — when to use each
+
+| Mechanism | How it works | When to use it |
+|---|---|---|
+| **`shamir`** | The master key is split into N shares using Shamir's Secret Sharing. Any M of those N shares reconstruct the key; possessing fewer than M shares reveals nothing. Each share is distributed to a separate custodian or secrets backend. At startup, Krypton fetches M shares from the configured backends and reconstructs the key in protected memory — the complete key never exists in any one place before this moment. | **Production environments.** This is the only mechanism that enforces true split-knowledge custody: no single person, system, or cloud provider can unseal Krypton alone. It satisfies PCI-DSS Req 3.7.2 (dual control for key operations), NIST SP 800-57 §8.2 (M-of-N key custodianship), SOC 2 CC6.1, and eIDAS 2.0 trust service requirements. Use this for any system that handles regulated, sensitive, or high-value data. |
+| **`stanza`** | A single pre-generated key is stored in one backend — a cloud KMS, a secrets manager, or a local encrypted file. Krypton fetches and uses it directly at startup, with no splitting or reconstruction step. The key can still be protected at rest by KMS-wrapping, so it is never stored as raw plaintext. | **Single-custodian or automated deployments.** Appropriate for CI/CD pipelines, staging environments, disaster-recovery automation, or deployments where the trust boundary is a single well-secured HSM. Simpler to operate than Shamir when split-knowledge is not a requirement. Not suitable where regulations mandate dual control. |
+| **`static-key`** | A raw AES-256 key is provided directly via an environment variable, a local file, or an embedded configuration value. Krypton loads it and starts immediately — no ceremony, no shard fetching, no unseal step. All sealed-state guards are disabled, so Krypton behaves as if it is always unsealed. A prominent warning is emitted at every startup to make accidental production use visible. | **Local development only.** Provides instant startup with zero infrastructure. Because there is no key ceremony and all seal guards are bypassed, this mechanism is completely unsuitable for any environment with real data. FIPS 140-3 mode explicitly rejects `static-key` because the standard requires master key material to be generated and stored through an approved, auditable mechanism. Never use in staging or production. |
+
+### Capability table
+
+| # | Capability | What it means |
+|---|---|---|
+| 42 | **Sealed-by-default startup** | On every start, Krypton refuses all cryptographic requests until its three master keys have been reconstructed from their configured sources. There is no way to bypass this requirement or pre-load key material before the unseal ceremony completes. Every seal and unseal event is recorded in the compliance audit log with actor identity, timestamp, and outcome, satisfying SOC 2 CC7 requirements for high-privilege administrative action auditing. |
+| 43 | **MasterKey — wrapping root of trust** | Wraps all lower-tier keys (IVK, domain, service, data). This is the highest-value key in the system — its ceremony is the most sensitive operational procedure an organisation performs with Krypton. It cannot be used for any purpose other than key-wrapping, preventing accidental misuse. |
+| 44 | **MasterCryptoKey — internal credential encryption** | Encrypts every sensitive credential stored in Krypton's database (cloud API keys, HSM PINs, provider passwords) and provides the asymmetric key pair operators use to submit new credentials securely from the command line. Separating it from MasterKey means that a breach of the credential store cannot be leveraged to attack the key hierarchy. |
+| 45 | **MasterSigningKey — key-blob integrity** | Signs every key blob written to the database and verifies the signature on every read. An attacker who gains write access to the database cannot substitute a malicious key without the substitution being detected. Separating it from MasterKey allows organisations to assign signing authority to a different custodian group than wrapping authority, enabling independent oversight. |
+| 46 | **`shamir` seal — production split-knowledge** | The master key is split into N shares (default: 8); any M (default: 6) reconstruct it. No single custodian, machine, or cloud account can unseal Krypton without cooperation. Satisfies PCI-DSS dual control, NIST SP 800-57 M-of-N custody, and eIDAS 2.0 trust service requirements. |
+| 47 | **`stanza` seal — single-custodian deployment** | One pre-generated key is stored in one backend. No splitting required. Appropriate for automated pipelines and environments with a single HSM as trust boundary. Supports KMS-wrapped storage so the key is never in plaintext at rest. Not appropriate where dual control is mandated by policy or regulation. |
+| 48 | **`static-key` seal — development only** | A raw AES key provided via configuration. Instant startup, zero infrastructure, all seal guards disabled. A prominent warning is always emitted. FIPS 140-3 mode rejects it. Must never be used in any environment with real or sensitive data. |
+| 49 | **Multi-cloud shard distribution** | Shamir shares can be distributed across any combination of backends: AWS KMS (KMS-wrapped), AWS Secrets Manager, GCP KMS (KMS-wrapped), GCP Secret Manager, Azure Key Vault Secret, Azure Key Vault RSA key (KMS-wrapped), HashiCorp Vault Transit (KMS-wrapped), HashiCorp Vault KV v2, and local encrypted files. No single cloud provider holds enough shares to unseal alone. Each backend is an independent plugin, so new backends can be added without changing the core system. |
+| 50 | **KMS-wrapped shard storage** | When a cloud KMS is used as a shard backend, the shard payload is wrapped (encrypted) by a KMS key before it is stored. The plaintext shard only exists briefly in memory during the unseal ceremony and is never written to any persistent storage in unprotected form. This means even an attacker who reads the shard database record cannot use it without also compromising the corresponding KMS key. |
+| 51 | **Shard fingerprint verification** | Every shard is assigned a SHA-256 fingerprint of its plaintext content at the time the ceremony is run. When a shard is retrieved during unsealing, its content is verified against this fingerprint before it is accepted. A shard that has been tampered with, corrupted in storage, or replaced with a different shard is rejected before it can corrupt the reconstructed master key. |
+| 52 | **Live unseal progress streaming** | Operators unsealing Krypton can watch the progress of each individual shard attempt in real time: which shards succeeded, which failed, and how many are still needed to reach the quorum threshold. This is essential during emergency unsealing situations where operators need to coordinate across time zones or multiple custodians. |
+| 53 | **Shard health validation** | At any time — not only during unsealing — operators can run a dry-run probe against all registered shards. Each shard is fetched and verified against its fingerprint, but the master key is never reconstructed. This surfaces unreachable backends, expired cloud credentials, or corrupted shards before they become a problem during an actual unsealing event. |
+| 54 | **Quorum-based sealing** | Sealing Krypton (locking it down to halt all cryptographic operations) requires multiple custodians to cast votes within a time-limited session. A single operator — or a single compromised credential — cannot seal the server unilaterally. The voting session expires automatically if the threshold is not reached, preventing a denial-of-service attack where a malicious actor tries to seal the server indefinitely. |
+| 55 | **Shard lifecycle management** | Individual shards can be registered with new backends, retired (soft-disabled without deletion), restored from retirement, or permanently deleted. All operations require explicit confirmation for irreversible actions. This allows organisations to rotate shard storage backends, decommission old backends, or respond to a suspected shard compromise without rerunning the full ceremony. |
+| 56 | **Ceremony fault tolerance** | When running the initial key-generation ceremony that produces and distributes all shares, a failure uploading one share to one backend does not abort the entire ceremony. Failed uploads can be retried or skipped; successfully completed uploads are not repeated. After the ceremony, a manifest file records every shard reference and its fingerprint, which serves as the audit record for the ceremony and as a recovery guide if any shard later needs to be re-registered. |
+
+---
+
+## 7. External Key Providers
+
+*How Krypton delegates the outermost key-wrapping to cloud KMS services and hardware security modules.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 57 | **AWS KMS integration** | Krypton wraps domain keys using an AWS Customer Managed Key. The wrapping and unwrapping operations are performed by AWS KMS; the raw key material never exists outside the AWS boundary. Krypton holds the inner key layers; AWS holds the outer wrapper. Neither side can read application data alone. This enables AWS customers to maintain key custody within their AWS account while using Krypton for all key lifecycle management. |
+| 58 | **Azure Key Vault integration** | Same trust model as AWS KMS, using Azure Key Vault RSA or EC keys as the outer wrapper. Can be used alongside AWS in a dual-provider configuration, so neither cloud provider alone can unwrap Krypton's keys — eliminating single-cloud dependency for the highest-value wrapping layer. |
+| 59 | **GCP Cloud KMS integration** | Google Cloud KMS symmetric or asymmetric keys as the outer wrapper. Supports Cloud HSM-backed keys, meaning the wrapping key can be held in a FIPS 140-3 Level 3 HSM operated by Google. |
+| 60 | **HashiCorp Vault / OpenBao integration** | Uses the Transit Secrets Engine as an external wrapping provider. Suitable for organisations that run their own Vault cluster on-premises or in a private cloud, where neither AWS, Azure, nor GCP is the appropriate trust anchor. OpenBao is the open-source continuation of Vault and uses the same integration. |
+| 61 | **PKCS#11 HSM integration** | Any hardware security module that conforms to the PKCS#11 standard — including Thales, Entrust, IBM, nCipher, and others — can be used as the outermost wrapping provider. The HSM holds the wrapping key in tamper-resistant hardware. This is the highest security option for the ExternalRoot tier, suitable for environments that require FIPS 140-3 Level 3 or Common Criteria certification for key storage. |
+| 62 | **Dual-provider key wrapping** | A single domain key can be wrapped simultaneously and independently by two different external providers — for example, one AWS KMS key and one Azure Key Vault key. To unwrap the domain key, both providers must respond successfully. If one provider is breached or becomes unavailable, the other still protects the key. This completely eliminates single-cloud lock-in for the highest-security wrapping tier and satisfies the redundancy requirements for critical key material. |
+| 63 | **Fallback KMS/SecretStorage provider chain** | If the designated primary external provider for a key is unavailable — due to a network outage, a KMS-side incident, or expired credentials — Krypton automatically attempts the operation with configured fallback providers in order. The application and its users see no interruption. Fallback attempts and their outcomes are recorded in the audit trail. |
+
+---
+
+## 8. Protocols & APIs
+
+*How external systems talk to Krypton.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 64 | **gRPC API** | The primary programmatic interface for machine-to-machine communication. gRPC uses a compact binary encoding and supports streaming, making it the most efficient option for high-throughput workloads. Every Krypton capability — key creation, encryption, signing, lifecycle management, audit queries — is available through this API. |
+| 65 | **REST / HTTP-JSON API** | Every operation available via gRPC is also accessible through a standard HTTP/JSON REST interface. This allows any HTTP client — a browser, a shell script, a service that cannot use gRPC — to interact with Krypton without any special library. The REST and gRPC APIs are always in sync: adding a new operation to one automatically adds it to the other. |
+| 66 | **KMIP 1.0–1.4 server** | The OASIS Key Management Interoperability Protocol is the industry standard for communicating with hardware security modules, encrypted database engines (Transparent Data Encryption), payment terminals, SIM card provisioning systems, and network encryption appliances. Krypton implements KMIP fully, meaning any system that already talks to an HSM can talk to Krypton without modification — Krypton is a software drop-in replacement for a hardware HSM. |
+| 67 | **KMIP delegation from edge to core** | When a KMIP request arrives at an edge Krypton node for an operation the edge does not have the authority to perform locally, it transparently forwards the request to the central authority for execution. The caller's identity is preserved across the delegation, so the central authority's audit trail reflects the original caller rather than the edge node. This works over both TCP and HTTP transport, matching the capabilities of the KMIP client. |
+| 68 | **GraphQL API with real-time subscriptions** | Developers who prefer a query-based interface can interact with Krypton through GraphQL. This is particularly useful for building dashboards and admin interfaces that need to query related resources (keys, policies, audit events) in a single request. WebSocket subscriptions allow a client to register interest in specific events — such as a key rotation completing — and receive a push notification when that event occurs, without polling. |
+| 69 | **kryptonctl operator CLI** | A command-line tool for operators that covers tasks not suited to API calls: running the offline key ceremony, inspecting stored blobs without a live server connection, encrypting credentials before submitting them to the server, probing shard health, managing the unseal ceremony interactively, and generating and rotating master keys. The CLI is designed so that no sensitive value ever needs to be typed in plaintext into a terminal that could be logged. |
+
+---
+
+## 9. Distributed Deployment
+
+*How Krypton runs across multiple datacentres and geographic regions.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 70 | **Central authority and edge topology** | The central authority holds the highest-value keys (master key, IVK, domain keys) and runs in a well-secured, highly available environment. Edge nodes are deployed physically close to applications — in the same datacenter, the same region, or on the same network segment — and hold only the leaf data keys their local applications need. This means encryption and decryption operations by applications have microsecond latency to a local edge node, not round-trip latency to a distant central authority. |
+| 71 | **Transparent remote key delegation** | When an edge node receives a request that requires a key tier it does not manage locally — for example, a request to rotate a domain key — it forwards the operation to the central authority and returns the result to the caller. From the caller's perspective, this is a single, synchronous operation. This design keeps sensitive higher-tier key material out of the edge environment while still allowing the full range of key management operations from any node. |
+| 72 | **Durable distributed event bus** | All key lifecycle events, audit records, and configuration changes that need to propagate across nodes travel over a durable, ordered event pipeline. Events are delivered at least once and can be replayed from any point in the history. If a node is temporarily offline, it catches up when it reconnects by replaying the events it missed. Without durability and replay, a node restart would cause it to miss events, leading to stale state and inconsistent key versions across the cluster. |
+| 73 | **Strict geographic data residency** | Each Krypton node knows which geographic region it serves. When strict residency mode is enabled for a key tier, Krypton refuses to route a key operation to a node in a different region — even if the local node is temporarily unavailable. The operation fails with an explicit error rather than silently using a node in an unintended jurisdiction. This is a hard technical control for GDPR Art. 25 data-residency requirements and similar regulations that prohibit data processing outside specified geographic boundaries. |
+| 74 | **Multi-node cluster consensus** | When multiple central-authority nodes run together for high availability, they use a consensus protocol to agree on cluster-wide state changes. A change (such as a policy update or a master key rotation) takes effect only after a majority of nodes have confirmed it. This prevents split-brain scenarios where different nodes believe different states and make contradictory decisions. |
+| 75 | **Edge resilience with local caching** | Edge nodes cache pre-wrapped data keys from the central authority. If the connection to the central authority is interrupted — due to a network partition, a CA maintenance window, or a regional outage — the edge node continues serving encryption and decryption operations for already-cached keys. Only operations that genuinely require the CA (such as creating a new key or rotating an existing one) are affected by the outage. Without caching, a CA connectivity loss would immediately halt all encryption operations at the edge. |
+
+
+---
+
+## Compliance & Governance
+
+*How Krypton helps organisations meet regulatory and security requirements.*
+
+| # | Capability | What it means |
+|---|---|---|
+| 76 | **FIPS 140-3 algorithm enforcement** | When FIPS mode is enabled, only cryptographic algorithms that are approved under FIPS 140-3 are available. Non-FIPS algorithms are disabled at the operating level — they cannot be selected even by an operator with full administrator access. DES, 3DES, HMAC-MD5, and new AES-CBC key generation are blocked unconditionally, regardless of FIPS mode, because they are either deprecated or disallowed. This means a Krypton deployment can credibly certify that no disallowed algorithm was used anywhere in the system, which is a prerequisite for FedRAMP, DoD, and many financial-sector compliance frameworks. |
+| 77 | **NIST SP 800-57 key lifecycle compliance** | The key state machine, transition rules, mandatory metadata fields, and cryptoperiod enforcement all directly implement NIST SP 800-57 Part 1 guidance on key management. Every key version records its algorithm, key length, activation timestamp (the start of its cryptoperiod), and creation origin. Cryptoperiods are enforced at the point of use, not only during cleanup sweeps. Compliance auditors can verify that every key in the system meets the NIST-required controls without needing to inspect any code. |
+| 78 | **NIST SP 800-108 key derivation binding** | Whenever a key is derived from another key, the intended purpose and output length are bound into the derivation input, following NIST SP 800-108 Fixed Input Data requirements. This prevents key confusion attacks where two keys derived for different purposes from the same parent could turn out to be identical if the derivation is done carelessly. Every derived key is cryptographically tied to its intended use. |
+| 79 | **NIST SP 800-131A algorithm transition enforcement** | NIST SP 800-131A Rev 2 defines which algorithms are approved, deprecated, or disallowed for federal use. Krypton enforces these transitions in the code, not merely in documentation: DES and 3DES cannot be used for any new operations, HMAC-MD5 is removed entirely, RSA signatures use only PSS padding, and HMAC-SHA-1 is available only for verifying legacy signatures with an enforced minimum key size. An organisation that runs Krypton can demonstrate to auditors that disallowed algorithms are technically impossible to use — not merely prohibited by policy. |
+| 80 | **PCI-DSS v4 audit record completeness** | Every key lifecycle event that Krypton records automatically carries the complete set of fields required by PCI-DSS v4 Requirement 10.3.1: a UTC timestamp, the identity of the actor who triggered the event, the type of actor (human user, service account, or automated system), the source IP address, and the outcome (success or failure). These fields cannot be omitted — they are populated automatically from the request context. This means a PCI-DSS audit of key management records will find complete, consistent records for every event, with no gaps that would require manual investigation. |
+| 81 | **GDPR Art. 25 geographic data residency** | Key operations can be configured to be served only by nodes in specific geographic regions. When strict residency mode is active, if the geo-routing system cannot confirm the correct region, the operation fails rather than silently processing in an unintended jurisdiction. This is a technical implementation of privacy-by-design as required by GDPR Article 25 — the data residency boundary is enforced by the system, not by administrative procedure alone. |
+