Secrets & Key Management Policy

Document owner: [Owner/Role]
Approved by: [Steering Committee / CISO]
Effective date: [YYYY-MM-DD]
Review cadence: [Annually]

1. Purpose & Scope

This policy establishes mandatory requirements for the generation, storage, access, rotation, and retirement of secrets and cryptographic keys — API keys, service credentials, TLS certificates, encryption keys, and signing keys — across [Organization] systems. It applies to all employees, contractors, and systems that create or consume secrets.

This policy is the canonical source for cryptographic algorithm/parameter standards and kill-chain secret handling referenced elsewhere in this repository (e.g., Password Policy §2.13, Password Policy (M365/AD) §2.13).

2. Policy Statements

2.1 Secret Inventory & Ownership

Every secret must have a named owner and a documented purpose.
An inventory of active secrets must be maintained in the approved secret manager; secrets with no identifiable owner must be rotated and reassigned or retired within 30 days of discovery.

2.2 Storage

Secrets must be stored only in an approved secret manager, key vault, or HSM.
Secrets must not be stored in source code, config files committed to version control, tickets, chat messages, or shared documents.
Any secret found outside an approved store must be treated as compromised: rotated immediately, not just relocated.

2.3 Cryptographic Standards

Purpose	Approved	Minimum Parameters
Password hashing	Argon2id (preferred), bcrypt, PBKDF2	Argon2id: memory ≥19 MiB, iterations ≥2; per-credential unique salt ≥128 bits
Symmetric encryption at rest	AES-256-GCM	Unique IV/nonce per operation
Transport encryption	TLS 1.2 minimum, TLS 1.3 preferred	Modern cipher suites only; disable TLS 1.0/1.1
Asymmetric keys	RSA ≥3072-bit, ECDSA P-256 or higher	—
Signing	Ed25519 or ECDSA P-256+	—
Legacy/weak algorithms (MD5, SHA-1 for integrity, DES/3DES, RC4, NTLMv1)	Prohibited for new use; existing use tracked as a remediation item	—

2.4 Access Control

Access to secrets must follow least privilege and, where supported, just-in-time elevation.
All secret retrieval must be logged (who, what, when).
Human access to production secrets should be exceptional and time-bound; services must authenticate via managed identity/certificate rather than a retrieved static secret where the platform supports it.
AI Agent (Autonomous) accounts (per Authentication Policy §3.1) must not hold a static long-lived credential equivalent to a service account password. Agent credentials must be short-lived and scoped to the task/session, expiring automatically at task completion — a compromised agent session should not yield a standing key an attacker can reuse after the session ends.

2.5 Kill-Chain Secrets (Barbell Principle)

Secrets gating existential systems — PKI/CA root passphrases, backup/DR encryption master keys, break-glass vault master credentials, HSM activation secrets — must receive protection disproportionate to ordinary secrets:

Split-knowledge / dual control: no single person holds the complete secret.
Physical or HSM-backed storage, not a general-purpose secret manager.
Real-time alerting on access; access requires a second approver.
Do not spread equivalent extra effort across low-value secrets — concentrate paranoia here; keep §2.2–§2.4 lean everywhere else.

2.6 Rotation & Expiry

Secret Type	Rotation Cadence
Human-facing passwords	Incident-driven only (no scheduled expiry, per Password Policy §2.3)
Service account secrets / API keys	Automated, ≤90 days
TLS certificates	Before expiry, automated renewal preferred
Kill-chain secrets (§2.5)	Annually, or immediately after any custodian change
Any secret suspected compromised	Immediately

2.7 Secret Compromise Response

A suspected or confirmed secret compromise must trigger immediate rotation, revocation of derived sessions/tokens, and a structural post-mortem per Authentication Policy §2.12.

2.8 Enforcement

Violations may result in disciplinary action or revocation of access.
Secrets discovered in version control history must be rotated even after removal from the current commit — history does not un-leak a secret.

3. Antifragility Alignment

This policy is built to the five pillars of the organization's internal Antifragile Enterprise Manifest.

Pillar	Applied In	How
1. Structural Decoupling	§2.4	Services authenticate via managed identity/certificate rather than a portable static secret where possible — removes a class of dependency entirely
2. Optionality Preservation	§2.3	Standardized, non-proprietary algorithms (AES, Argon2id, ECDSA) avoid lock-in to a single vendor's crypto scheme
3. Stress-to-Signal Conversion	§2.7	Every compromised secret forces a structural post-mortem, not just a quiet rotation
4. Sovereign Intelligence	§2.1	Named owner per secret; inventory is owned and current, not tribal knowledge of "whoever set it up"
5. Asymmetric Payoff Design (Barbell)	§2.5	Split-knowledge/HSM concentrated on kill-chain secrets; ordinary secrets get the lean baseline — nothing moderate spread everywhere

6.0 KiB Raw Blame History