Planned payload protection and versioning
The target Federated Trust Vault payload suite is AES-256-GCM in versioned encryption envelopes. Deployment documentation must identify the active suite and its evidence before describing that control as implemented.
Authenticated encryption
AES-GCM protects confidentiality and detects unauthorized changes when nonces, keys, and associated data are handled correctly.
Keys are separate authority
Ciphertext storage, encryption-key custody, and authorization are separate responsibilities; possession of one should not imply the others.
No universal key target
The target architecture avoids a single provider-wide decryption key across unrelated organizations.
Federated Trust Vault is not generally available. Its planned payload suite is AES-256-GCM in versioned envelopes, subject to deployment and cryptographic evidence.
Governing reference for Galois/Counter Mode authenticated encryption. Reference use does not assert FIPS module validation.
Organization visibility requires an encryption custody policy
If a business must recover credentials created by an employee, that item must be stored as business-owned encrypted material and wrapped to an approved organization custodian or recovery quorum.
Disclose the boundary
People should be told when an organizational vault is recoverable by authorized business custodians.
Separate personal vaults
Personal material should remain outside organization recovery unless the owner makes a distinct, informed grant.
Support is delegated
A partner can assist only when the tenant grants a scoped recovery role, key recipient, or quorum share under the applicable profile.
Explicit organization-custodian and multi-party recovery workflows are planned. They never turn an authentication password into recoverable data.
Pepper protects a verifier; it does not reveal a password
One-way authentication
A password verifier is designed to confirm a password without storing a recoverable copy of that password.
Pepper is defensive input
A separately held pepper can make stolen verifier data harder to attack, but losing or rotating it can require users to reset passwords.
Custody follows the authentication realm
The Federated Trust operator controls the versioned pepper for a Federated Trust-hosted sign-in realm. A business operating an isolated tenant-local or sovereign realm controls that realm’s separate pepper and reset plan.
Vault encryption is the business feature
Recoverable shared passwords belong in encrypted vault items governed by organization custody and access policy.
Explicit organization-custodian and multi-party recovery workflows are planned. They never turn an authentication password into recoverable data.
Governing reference for risk-based identity proofing, authentication, federation, privacy, and lifecycle decisions. Assurance outcomes are service-specific.
Post-quantum readiness is a migration program
The crypto-agility plan targets hybrid recipient envelopes and selected durable signatures. It does not describe today’s symmetric encryption as post-quantum public-key encryption.
Key establishment
ML-KEM is planned for post-quantum key establishment after implementation and interoperability validation.
Durable signatures
ML-DSA and SLH-DSA are planned candidates for long-lived manifests, key-directory material, and audit checkpoints where appropriate.
Algorithm agility
Envelope records need explicit suite, key, and version identifiers so recipients can migrate and reject downgrade attempts.
Roadmap target for post-quantum key establishment in versioned, crypto-agile recipient envelopes after implementation and interoperability validation.
ML-DSA (FIPS 204)Roadmap target for selected durable signatures such as manifests and key-directory material, not a claim about current tokens.
SLH-DSA (FIPS 205)Roadmap target for selected long-lived signature use cases where its security and performance tradeoffs fit.
NIST SP 800-227Roadmap reference for selecting and using key-encapsulation mechanisms as the post-quantum envelope profile matures.