security-canon/infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md

id	title	short_name	type	standard_family	repository_context	recommended_path	status	version	canonical_owner	namespace	classification	abstraction_layer	primary_cluster	conformance_posture	imports	related	owned_concepts	provenance
sec-dsm:DevOpsSecretsManagementStandard	SecurityCanon DevOps Secrets Management Standard	SEC-DSM	standard	SecurityCanon	security-canon	standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md	stable	1.0.0	SecurityCanonDevOpsSecretsManagementStandard	sec-dsm	standard	standard	secrets-management	normative	InfoTechCanonCore InfoTechCanonAccessControlModel InfoTechCanonIdentityModel InfoTechCanonOrganizationModel sec-authority:ModeOfAuthority	sec-authority:ModeOfAuthority InfoTechCanonCaringAccessGovernanceStandard	SecretsPreferenceHierarchy DynamicCredential ProducerCredential SecretsDecisionProcedure SecretsException	source_file source_sha256 inserted insertion_decision DevOpsSecretsManagementCanon-v1.0.md ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f 2026-10-11 SECURITY-DEC-2026-004

SecurityCanon DevOps Secrets Management Standard

Short name: SEC-DSM Document status: Stable standard Version: 1.0.0 Repository context: security-canon Document type: SecurityCanon domain standard Conformance posture: Normative (RFC 2119, as stated in the body)

Position in SecurityCanon

This artifact is a Tier-3 standard. It states what a secrets-management practice must do. It does not operate custody, issue credentials, or render an authorization decision.

SecurityCanon owns the practice requirements in the body (DSM-*), the preference hierarchy, and the decision procedure. Shared roots stay where SEC-ADR-001 and concept placement put them. Section 4 of the inserted text uses Principal, Secret, Credential, and Capability as working language for this practice. That use does not transfer ownership and does not redefine the upstream concept:

Term in the body	How to read it here
Principal	The InfoTechCanon access-control Principal. This standard does not define a second one.
Authority	The InfoTechCanon organization-model Authority. Auth Mode qualifies how it is exercised.
Capability	The InfoTechCanon capability, used here as authority to perform an operation. Not a second Capability concept.
Scope	The InfoTechCanon identity-model Scope, when the body means a boundary. A credential's "scope" in the ordinary engineering sense is the authority it grants, and the body says so in place.
Secret, Credential	Practice terms for material whose disclosure grants or enables authority. No upstream artifact currently owns a competing definition. If one is later declared, this standard imports it.
Identity Assertion	Practice term for short-lived evidence of identity. Identity itself stays in InfoTechCanon.

Estate application belongs to the consumers. Gate House teaches and supervises. secrets-engine materializes credentials. ops-mason builds routes. ops-warden operates lanes. A NetKingdom obligation that is stricter than this standard is the estate's to record. This standard is not edited to fit one estate.

The body below is the inserted source, unchanged. Provenance file DevOpsSecretsManagementCanon-v1.0.md, SHA-256 ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f, adopted by SECURITY-DEC-2026-004 on 2026-10-11.

---

DevOps Secrets Management Canon

Version: 1.0
Status: Stable Canon
Domain: DevOps, Platform Engineering, Identity, Security, CI/CD, Runtime Operations

---

1. Purpose

The DevOps Secrets Management Canon defines a technology-independent model and normative practices for managing credentials, cryptographic material, workload authentication, and secret-bearing capabilities across software-development and production environments.

Its strategic objective is:

Reduce persistent secrets to governed exceptions and prefer identity-mediated, short-lived capabilities wherever possible.

Secrets management is therefore not primarily a storage problem.

It is the discipline of controlling an authority lifecycle:

avoid
  ↓
identify
  ↓
authorize
  ↓
issue
  ↓
deliver
  ↓
consume
  ↓
renew / rotate
  ↓
expire / revoke
  ↓
detect
  ↓
recover
  ↓
audit

The desired end state is not a better collection of passwords.

It is an environment in which principals authenticate through identity and receive narrowly scoped capabilities only for the time they require them.

When a target can authorize a principal directly through trustworthy native or federated identity, that direct path is generally preferable to introducing an additional secret or credential broker.

---

2. Normative Language

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, and OPTIONAL are to be interpreted according to BCP 14 / RFC 2119 and RFC 8174 when, and only when, they appear in uppercase.

A MUST expresses a requirement necessary for full conformance unless an explicitly governed exception exists.

A SHOULD expresses a strong recommendation that may be violated when the trade-off has been consciously evaluated and documented.

A MAY expresses a legitimate implementation choice.

---

3. Scope and Intended Audience

The canon applies to secrets and credential-like capabilities used by:

• humans;
• CI/CD pipelines;
• build systems;
• deployment systems;
• applications;
• containers;
• Kubernetes workloads;
• infrastructure automation;
• autonomous or semi-autonomous agents;
• service-to-service communication;
• databases;
• cloud providers;
• third-party APIs;
• signing systems;
• certificate authorities;
• recovery procedures.

The canon is primarily intended for production environments and non-trivial engineering organizations.

Smaller teams and early-stage systems SHOULD use the preference hierarchy, decision procedure, and Minimum Viable Adoption Profile without assuming they must immediately operate a full capability-broker architecture.

The canon describes a direction of travel, not a requirement to maximize architectural sophistication regardless of cost.

---

4. Core Concepts

4.1 Principal

A Principal is an entity that may be authenticated.

Examples include:

• human;
• CI job;
• Kubernetes workload;
• service;
• repository;
• deployment;
• build agent;
• autonomous agent.

Principals SHOULD have individual identities rather than inheriting shared credentials.

---

4.2 Identity Assertion

An Identity Assertion is short-lived evidence establishing the identity or relevant attributes of a principal.

Examples include:

• OIDC token;
• projected Kubernetes ServiceAccount token;
• SPIFFE SVID;
• cloud workload-identity assertion;
• hardware-backed human authentication.

An identity assertion is not equivalent to an ordinary application secret.

---

4.3 Secret

A Secret is information whose unauthorized disclosure grants, contributes to, or meaningfully enables authority not intended for the observer.

Examples include:

• password;
• API token;
• private key;
• symmetric encryption key;
• OAuth client secret.

---

4.4 Credential

A Credential is material presented to establish identity or exercise authority.

A credential MAY itself be secret.

Credentials may be:

static
rotated
leased
ephemeral
derived
federated

---

4.5 Capability

A Capability is authority to perform a particular operation against a resource.

Examples:

read bucket X
write table Y
deploy service Z
sign artifact A
publish image B

A capability does not necessarily require possession of a persistent secret.

---

4.6 Dynamic Credential

A Dynamic Credential is generated on demand for a particular consumer or execution and possesses a defined lifetime.

Examples include:

• temporary database account;
• cloud STS credential;
• SSH certificate;
• short-lived X.509 certificate;
• temporary access token.

---

4.7 Producer Credential

A Producer Credential authorizes creation or issuance of other credentials.

Examples include:

• database administrator authority used by a broker to create temporary users;
• CA signing authority;
• cloud role capable of issuing temporary credentials.

Producer credentials are intrinsically high-value assets.

---

4.8 Secrets Authority

The Secrets Authority is the authoritative control plane responsible for one or more secret or credential lifecycles.

A Secrets Authority MAY:

• store secrets;
• issue credentials;
• broker capabilities;
• rotate credentials;
• revoke credentials;
• enforce policy;
• record audits.

---

4.9 Issuer

An Issuer creates a credential or identity assertion.

The issuer MAY differ from the Secrets Authority.

For example:

Secrets Authority → requests database credential
Database          → creates database principal

or:

CI platform → issues OIDC assertion
Cloud STS   → issues temporary cloud credential

---

4.10 Delivery Adapter

A Delivery Adapter transports secret material from an authority to a consumer.

Examples include:

• direct API;
• secrets agent;
• CSI driver;
• External Secrets Operator;
• temporary filesystem;
• injected environment variable.

A delivery adapter MUST NOT implicitly be considered the authoritative source of the secret.

---

4.11 Root of Trust

A Root of Trust is authority that cannot itself depend entirely upon the normal secrets-management hierarchy.

Examples include:

• HSM root key;
• root CA;
• recovery key;
• bootstrap key;
• platform-root authority.

Roots of trust SHOULD be few, explicit, and exceptionally protected.

---

4.12 Standing Authority

Standing Authority is authority available to a principal independently of an immediate task.

Examples include:

• long-lived API tokens;
• persistent administrative accounts;
• permanent cloud access keys;
• broad agent credentials.

Reducing standing authority is a primary objective of the canon.

The preference hierarchy, maturity model, and exposure model should all be interpreted partly as mechanisms for reducing standing authority.

---

5. Preference Hierarchy

Implementations SHOULD prefer mechanisms in the following order:

1. Native identity with no transferable secret
2. Federated / workload identity
3. Ephemeral dynamically issued credential
4. Automatically rotated credential
5. Centrally managed static secret
6. Manually managed static secret

Moving downward SHOULD require increasing justification.

Moving upward generally reduces one or more of:

• standing authority;
• credential lifetime;
• credential replication;
• number of eligible consumers.

This hierarchy is not absolute.

The correct architecture is the highest practical level that provides acceptable reliability, operational cost, compatibility, and security for the system concerned.

---

6. Transitional and Constrained Environments

Not every target supports federation, dynamic credentials, or modern workload identity.

Typical constraints include:

• legacy databases;
• appliances;
• old protocols;
• third-party APIs exposing only static tokens;
• SaaS platforms with manually generated API keys;
• network devices;
• software that reads credentials only during startup;
• rate-limited or unavailable credential issuers.

The canon does not require constructing elaborate intermediary systems merely to simulate ephemeral credentials where doing so creates more operational risk than it removes.

DSM-TRANS-001 — Highest Practical Mechanism

A system SHOULD use the highest mechanism in the preference hierarchy that the target and operating environment can reliably support.

DSM-TRANS-002 — Govern the Residual Secret

When a static credential cannot reasonably be eliminated, it MUST receive:

• explicit ownership;
• central authoritative storage;
• minimum feasible scope;
• rotation policy;
• revocation procedure;
• inventory coverage;
• leak detection where practical.

DSM-TRANS-003 — Do Not Fake Dynamism

A platform SHOULD NOT add complex credential issuance layers merely to claim dynamic-secret maturity when the resulting architecture increases failure probability without materially reducing authority, lifetime, or exposure.

DSM-TRANS-004 — Record Elimination Potential

Persistent credentials SHOULD record whether elimination depends on:

• target-system modernization;
• vendor capability;
• protocol migration;
• platform work;
• contract change;
• application redesign.

This turns persistent secrets into visible engineering debt.

DSM-TRANS-005 — Account for Issuer Dependency

Systems using dynamic credentials MUST consider failure of the credential issuer.

Relevant design concerns include:

• issuer availability;
• issuance latency;
• rate limits;
• lease renewal failure;
• clock skew;
• transient identity-provider failure;
• dependency during disaster recovery.

DSM-TRANS-006 — Degraded Operation

Where continued operation during issuer outage is necessary, the system SHOULD define a deliberate degraded-operation strategy.

Examples include:

• use of an already valid lease until expiry;
• local credential-agent caching within bounded TTL;
• fail-closed behavior;
• tightly governed emergency credentials.

Indefinite caching MUST NOT silently convert ephemeral credentials into persistent credentials.

---

7. Fundamental Requirements

DSM-ARCH-001 — Minimize Persistent Secrets

Systems MUST attempt to eliminate persistent credentials when equivalent authority can be provided using native or federated identity.

DSM-ARCH-002 — Static Secrets Are Exceptions

Long-lived static credentials MUST be treated as managed exceptions rather than the preferred authentication mechanism.

Each material static production secret MUST have:

• owner;
• purpose;
• consumers;
• authority;
• rotation policy;
• revocation procedure.

DSM-ARCH-003 — Separate Identity From Authority

Authentication and authorization MUST be treated as separate decisions.

Proof that a workload is service-A MUST NOT by itself imply unrestricted access to resources associated with service-A.

DSM-ARCH-004 — Separate Control Plane From Delivery

The authoritative secrets-management system SHOULD be distinguishable from delivery mechanisms.

Kubernetes Secrets, CI variables, mounted files, and environment variables SHOULD NOT be considered canonical sources when another authoritative system exists.

DSM-ARCH-005 — Optimize for Operability

Security architecture MUST account for availability and operational failure.

A theoretically stronger credential model SHOULD NOT be adopted without considering whether failures will cause teams to bypass it.

---

8. Developer Experience and Adoption

Security mechanisms that are difficult to use create incentives for unmanaged credentials.

The preferred mechanism SHOULD therefore also become the normal engineering path.

DSM-DX-001 — Secure Path of Least Resistance

Platform teams SHOULD make the preferred identity and credential mechanism easier to adopt than unmanaged static secrets.

DSM-DX-002 — Golden Paths

Organizations operating shared platforms SHOULD provide reusable integrations such as:

• CI templates;
• deployment templates;
• workload-identity modules;
• Terraform modules;
• Helm components;
• SDK helpers;
• secrets-policy templates.

DSM-DX-003 — Self-Service

Routine credential and identity provisioning SHOULD be self-service where policy permits.

Security teams SHOULD NOT become a manual transport layer for ordinary application credentials.

DSM-DX-004 — Local Development

The secrets architecture SHOULD define an explicit development workflow.

Local development SHOULD prefer:

• developer identity;
• development-only authority;
• temporary credentials;
• local emulation.

Production credentials SHOULD NOT be required for normal development.

Non-normative implementation note

Where integration testing requires real external services, useful patterns include:

• developer-scoped cloud roles;
• short-lived developer credentials;
• isolated test tenants;
• sandbox APIs;
• contract testing;
• service emulation;
• explicitly time-bounded and audited exceptional production access for debugging.

Such mechanisms should preserve the separation between routine development and production authority.

DSM-DX-005 — Debuggability

Identity and federation failures SHOULD be diagnosable without revealing secret values.

Useful diagnostics include:

• authenticated principal;
• token issuer;
• intended audience;
• policy decision;
• requested capability;
• denial reason;
• credential expiry.

DSM-DX-006 — Avoid Security Escape Hatches Becoming Defaults

Break-glass tokens, personal access tokens, manually copied credentials, and similar compatibility paths MUST NOT become undocumented normal workflows.

---

9. Identity Practices

DSM-ID-001 — Unique Workload Identity

Every security-relevant workload SHOULD possess its own identifiable runtime identity.

Production workloads MUST NOT depend upon a shared generic credential where individual workload identity is technically practical.

For systems claiming maturity level M3 or higher, unique workload identity is expected for applicable new production workloads unless an explicit exception exists.

DSM-ID-002 — Federated Authentication

Workloads SHOULD authenticate using environmental or federated identity.

Preferred mechanisms include:

• OIDC;
• cloud workload identity;
• Kubernetes workload identity;
• SPIFFE;
• equivalent cryptographically verifiable identities.

For systems claiming maturity level M3 or higher, federation or an equivalent non-static identity mechanism is expected for new integrations where supported by the target.

DSM-ID-003 — Eliminate Secret Zero

A workload SHOULD NOT require a long-lived bootstrap secret merely to authenticate to the secrets-management system.

DSM-ID-004 — Human and Machine Identity Separation

Human credentials and workload credentials MUST be distinguishable.

Human credentials MUST NOT be embedded into automated workloads.

Machine credentials SHOULD NOT routinely be used interactively by humans.

---

10. Authorization Practices

DSM-AUTH-001 — Least Authority

Credentials and capabilities MUST provide only the authority required for their intended operation.

DSM-AUTH-002 — Contextual Scope

Where supported, authorization SHOULD constrain:

principal
resource
operation
environment
time

Additional useful attributes include:

repository
branch
namespace
deployment
tenant
runtime
job
commit

DSM-AUTH-003 — Environment Isolation

Development, staging, and production authority MUST be independently scoped.

Compromise of a development credential MUST NOT inherently provide production authority.

DSM-AUTH-004 — Tenant Isolation

Credentials crossing tenant security boundaries MUST be explicitly modeled and authorized.

Shared credentials between independent tenants MUST NOT be used.

---

11. Issuance Practices

DSM-ISSUE-001 — Prefer Dynamic Issuance

When a target permits credentials to be issued dynamically, dynamic issuance SHOULD be preferred over retrieval of persistent credentials.

DSM-ISSUE-002 — Shortest Practical Lifetime

Dynamically issued credentials MUST have a bounded lifetime.

TTL SHOULD approximate the expected duration of the task plus reasonable operational margin.

DSM-ISSUE-003 — Per-Execution Credentials

Build jobs, deployment jobs, and autonomous-agent executions SHOULD receive credentials unique to the execution where supported.

DSM-ISSUE-004 — Producer Credential Protection

Producer credentials MUST receive stronger protection than ordinary consumer credentials.

They SHOULD use, where practical:

• workload identity;
• hardware protection;
• automated rotation;
• constrained network access;
• highly restrictive policy.

---

12. Storage Practices

DSM-STORE-001 — Authoritative Storage

Every persistent secret MUST have one identifiable authoritative source.

DSM-STORE-002 — Minimize Copies

Secret replication SHOULD be minimized.

Each additional persisted copy SHOULD be regarded as increased exposure surface.

DSM-STORE-003 — Encrypt at Rest

Persisted secrets MUST be cryptographically protected at rest.

Encryption keys SHOULD be governed independently from ordinary application access.

DSM-STORE-004 — No Plaintext Source Control

Plaintext credentials MUST NOT be committed to version-control systems.

DSM-STORE-005 — Git-Encrypted Secrets

Encrypted secrets MAY be stored in Git when declarative state provides a deliberate operational benefit.

Such storage:

• MUST use independently controlled encryption keys;
• MUST support key rotation;
• SHOULD restrict decryption to intended environments;
• MUST NOT be confused with dynamic secrets management.

---

13. Delivery Practices

DSM-DELIV-001 — Prefer Direct Consumption

Consumers SHOULD obtain capabilities directly from their authority or issuer when practical.

DSM-DELIV-002 — Minimize Persistence During Delivery

Credentials SHOULD remain resident for the minimum practical duration.

Preferred mechanisms include:

memory
ephemeral filesystem
short-lived local agent
direct request

DSM-DELIV-003 — Environment Variables

Environment variables containing high-value secrets SHOULD be avoided where safer delivery mechanisms exist.

They MAY be used for compatibility with software requiring them.

DSM-DELIV-004 — Kubernetes Secret Replication

Replication into Kubernetes Secret objects SHOULD occur only when required by the consuming workload or ecosystem.

DSM-DELIV-005 — Delivery Policy

Delivery adapters MUST NOT broaden authority beyond the policy of the authoritative system.

---

14. Rotation Practices

DSM-ROT-001 — Rotation Policy

Every persistent production credential MUST have a rotation policy.

DSM-ROT-002 — Automatic Rotation

Credentials that can reliably be rotated automatically SHOULD be rotated automatically.

DSM-ROT-003 — Rotation Includes Adoption

Rotation MUST NOT be considered complete merely because the authoritative value changed.

Complete rotation consists of:

issue
→ distribute
→ adopt
→ validate
→ revoke old

DSM-ROT-004 — Zero/Low-Downtime Rotation

Systems requiring continuous availability SHOULD support overlapping validity, dual credentials, or equivalent safe transition mechanisms.

DSM-ROT-005 — Dynamic Issuance Preferred

Where practical, dynamic issuance SHOULD replace periodic static-secret rotation.

---

15. Expiry and Revocation

DSM-REV-001 — Bounded Validity

Temporary credentials MUST expire automatically.

DSM-REV-002 — Explicit Revocation

Security-significant credentials SHOULD support explicit revocation in addition to expiry.

DSM-REV-003 — Known Revocation Procedure

Every persistent production credential MUST have a known method of revocation.

DSM-REV-004 — Compromise Response

A credential suspected of disclosure MUST be considered compromised.

Removing the exposed value from source code, logs, or configuration MUST NOT constitute sufficient remediation.

The credential MUST be revoked or replaced.

---

16. Detection Practices

DSM-DETECT-001 — Secret Detection

Repositories containing production software MUST use automated secret detection.

DSM-DETECT-002 — Layered Detection

Secret detection SHOULD occur at multiple boundaries where practical:

developer environment
push
repository
CI pipeline
logs
artifacts
runtime

DSM-DETECT-003 — Push Prevention

Organizations SHOULD prevent recognized credentials from entering source-control history where tooling can do so reliably.

DSM-DETECT-004 — Detection-to-Revocation

Detection mechanisms SHOULD integrate with automated or semi-automated revocation procedures.

A finding without a response mechanism is incomplete control.

---

17. CI/CD Practices

DSM-CI-001 — CI/CD Is Production Security Infrastructure

Any CI/CD system able to modify production MUST be treated as production-grade security infrastructure.

DSM-CI-002 — OIDC/Federation

CI jobs SHOULD exchange short-lived execution identity for external capabilities rather than use stored infrastructure credentials.

This requirement is platform-independent and applies to systems such as GitLab CI, GitHub Actions, cloud-native build services, and other CI platforms capable of workload federation.

DSM-CI-003 — Pipeline Change Authority

Authorization to modify security-relevant pipeline code MUST be considered capable of affecting the credentials obtainable through that pipeline.

DSM-CI-004 — Secret Masking Is Not Protection

CI log masking MUST NOT be treated as sufficient protection of credentials.

DSM-CI-005 — Job-Scoped Credentials

CI credentials SHOULD be scoped to individual jobs or executions and expire after execution completes.

---

18. Kubernetes Practices

DSM-K8S-001 — ServiceAccount Identity

Kubernetes workloads SHOULD use workload identity rather than static application credentials wherever supported.

DSM-K8S-002 — Projected ServiceAccount Tokens

Workloads requiring Kubernetes ServiceAccount tokens SHOULD use short-lived projected tokens obtained through the TokenRequest mechanism rather than legacy indefinitely valid ServiceAccount token Secrets.

Tokens SHOULD be:

• expiration-bound;
• audience-bound where supported;
• associated with the intended workload context.

DSM-K8S-003 — External Authority

Kubernetes SHOULD NOT become the default authoritative store for organization-wide high-value secrets when a dedicated authority exists.

DSM-K8S-004 — Native Cloud Identity Before Secret Brokerage

When the cloud platform can authorize a Kubernetes workload directly through native workload identity, that path SHOULD generally be preferred over routing the request through a secrets broker solely for credential issuance.

For example:

Pod identity
   ↓
cloud workload federation
   ↓
cloud API

may be preferable to:

Pod
 ↓
secrets authority
 ↓
temporary cloud credential
 ↓
cloud API

when both provide equivalent policy and audit guarantees.

DSM-K8S-005 — External Secrets Operator

External Secrets Operator MAY be used as synchronization and reconciliation infrastructure.

Its use MUST deliberately define:

• refresh behavior;
• ownership;
• deletion semantics;
• target namespace;
• access scope.

DSM-K8S-006 — Secrets Store CSI

Secrets Store CSI or equivalent runtime mounting SHOULD be considered when applications can consume file-mounted credentials.

Synchronization into Kubernetes Secret objects SHOULD remain disabled when unnecessary.

DSM-K8S-007 — Namespace Isolation

Access to secret material MUST be scoped according to workload and namespace boundaries rather than assuming namespace membership alone implies authority.

---

19. Cryptographic Key Practices

Credentials and data-encryption keys are related but distinct security objects.

A typical envelope-encryption hierarchy may contain:

KEK — Key Encryption Key
 ↓
DEK — Data Encryption Key
 ↓
encrypted application data

DSM-KEY-001 — Non-Exportability

High-value root keys, signing keys, and KEKs SHOULD be non-exportable where the workflow permits it.

DSM-KEY-002 — KMS/HSM

Root signing, encryption, wrapping, and similar high-value keys SHOULD use dedicated KMS or HSM facilities appropriate to their risk.

DSM-KEY-003 — Cryptographic Operations Instead of Key Retrieval

Applications SHOULD request cryptographic operations from trusted services rather than retrieve master keys when practical.

For example:

sign(data)
unwrap(DEK)
decrypt(small_payload)

is preferable to:

get_root_private_key()
get_KEK()

DSM-KEY-004 — Local Key Material

Applications MAY require temporary possession of key material such as DEKs when performing local high-volume encryption.

Such key material SHOULD:

• be narrowly scoped;
• have bounded lifetime where practical;
• avoid persistence;
• be wrapped by independently controlled KEKs.

DSM-KEY-005 — Keyless Signing

Software build and artifact-signing workflows SHOULD prefer ephemeral or keyless signing schemes where ecosystem compatibility permits.

---

20. Human Handling

DSM-HUM-001 — No Human Transport

Humans SHOULD NOT normally act as the transport mechanism for production secrets.

Examples include:

password manager → CI variable
chat → terminal
ticket → Kubernetes Secret
vault UI → .env

DSM-HUM-002 — Human Readability

Production credentials SHOULD NOT routinely require humans to view their plaintext value.

DSM-HUM-003 — Break Glass

Emergency human access MUST use explicitly identified break-glass procedures.

Break-glass activity MUST be:

• exceptional;
• attributable;
• auditable;
• time-bounded where practical.

---

21. Agents and Automated Systems

DSM-AGENT-001 — Agent Identity

Autonomous and semi-autonomous agents MUST authenticate using distinguishable workload identities.

DSM-AGENT-002 — Per-Run Identity

Where practical, agent executions SHOULD receive execution-specific identity.

Agent identity SHOULD be distinguishable at least by:

agent
run/task
environment
authority context

DSM-AGENT-003 — Short Agent Identity Lifetime

Agent identity and derived capabilities SHOULD have short bounded lifetimes related to task execution.

Capabilities SHOULD expire or be revoked when the task:

• completes;
• fails;
• is cancelled;
• loses authorization.

DSM-AGENT-004 — No Embedded Master Credential

Agents MUST NOT receive persistent platform-wide master credentials merely because their behavior is dynamic.

DSM-AGENT-005 — Capability Brokerage

Agents SHOULD request narrowly scoped capabilities when required rather than maintaining broad standing authority.

DSM-AGENT-006 — Deterministic Enforcement

Security boundaries controlling agent access to secret-bearing capabilities MUST use deterministic policy enforcement.

LLM reasoning MUST NOT constitute the sole authorization mechanism.

DSM-AGENT-007 — Prevent Credential Accumulation

Agent frameworks MUST NOT silently accumulate credentials across tasks.

Credential caches, tool contexts, memory stores, workspaces, and execution sandboxes SHOULD be cleared or invalidated according to task lifecycle.

DSM-AGENT-008 — Tool Authority Is Agent Authority

Authority reachable through an agent's tools MUST be included when evaluating the agent's effective security authority.

This includes intermediate tool and service credentials that the model itself cannot inspect or retrieve.

For example:

agent
  ↓
tool A
  ↓
service B
  ↓
credential C
  ↓
system D

If use of tool A allows the agent to cause actions in system D through credential C, the resulting authority is part of the agent's effective authority.

A hidden credential is not outside the security boundary merely because the model never sees its bytes.

---

22. Audit and Observability

DSM-AUDIT-001 — Audit Security-Relevant Operations

The secrets or capability authority MUST record applicable:

• authentication;
• authorization;
• retrieval;
• issuance;
• renewal;
• rotation;
• revocation;
• administrative changes.

DSM-AUDIT-002 — Never Audit Plaintext Secrets

Audit records MUST NOT contain plaintext secret values.

DSM-AUDIT-003 — Attribution

Audit records SHOULD identify:

principal
resource
operation
policy context
time
result
execution identity

DSM-AUDIT-004 — Audit Integrity

Security audit records SHOULD be protected from modification by systems and actors whose activity they record.

High-assurance environments SHOULD export audit evidence to an independent security domain.

DSM-AUDIT-005 — Identity Failure Observability

Authentication and federation failures SHOULD emit sufficient structured telemetry to diagnose:

• issuer mismatch;
• audience mismatch;
• token expiration;
• policy denial;
• trust-chain failure;
• lease failure;

without disclosing credentials.

---

23. Roots of Trust and Recovery

DSM-ROOT-001 — Enumerate Roots

Every deployment MUST identify its roots of trust.

Unknown roots constitute an architecture defect.

DSM-ROOT-002 — Minimize Roots

The number of roots of trust SHOULD be minimized.

DSM-ROOT-003 — Root Isolation

Root credentials MUST NOT be handled through ordinary application secret-delivery mechanisms unless the mechanism is explicitly designed for that assurance level.

DSM-ROOT-004 — Recovery

Recovery procedures MUST be documented and periodically tested.

DSM-ROOT-005 — Quorum for Extreme Authority

Where feasible, operations capable of compromising the entire secrets hierarchy SHOULD require multi-party authorization.

Non-normative topology note

High-assurance multi-region, multi-account, or multi-cluster deployments should explicitly model:

• which roots are shared and which are independent;
• cross-region or cross-account trust relationships;
• issuer failure boundaries;
• disaster-recovery trust bootstrap;
• audit paths crossing administrative boundaries;
• whether compromise of one cluster or account can mint authority in another.

Replication should not accidentally turn one regional or cluster root into an undocumented global root.

Independent audit sinks can be especially important where the same administrative plane controls several trust domains.

---

24. Inventory and Discovery

DSM-INV-001 — Secret Inventory

Organizations MUST maintain an inventory of security-significant persistent credentials.

DSM-INV-002 — Inventory Attributes

An inventory entry SHOULD contain:

id:
kind:
authority:
issuer:
owner:
consumers:
environment:
resources:
operations:
created_at:
expires_at:
rotation_policy:
revocation_method:
delivery_method:
classification:
maturity_level:
discovery_source:
verification_state:

DSM-INV-003 — Ownership

Every material production credential MUST have an accountable owner.

DSM-INV-004 — Automated Discovery

Inventory SHOULD combine declared information with automated discovery where practical.

Discovery sources MAY include:

• secrets authorities;
• CI variables;
• cloud IAM;
• Kubernetes;
• repositories;
• secret scanners;
• runtime telemetry;
• configuration systems.

DSM-INV-005 — Evidence State

Inventory systems SHOULD distinguish between:

declared
discovered
verified
inferred
unknown

information.

Discovery MUST NOT silently be treated as complete inventory.

DSM-INV-006 — Discovered but Unowned

A discovered production credential without a known owner MUST be treated as a security finding.

It SHOULD be:

1. contained if necessary;
2. attributed;
3. assigned an owner;
4. revoked if no legitimate use is established.

DSM-INV-007 — Orphan Detection

Secrets without known consumers SHOULD be investigated and revoked where legitimate use cannot be established.

---

25. Exception Management

DSM-EXC-001 — Explicit Exceptions

Violation of a MUST requirement MUST be represented as an explicit exception.

DSM-EXC-002 — Exception Record

An exception MUST record:

requirement
affected system
reason
owner
risk
compensating controls
approval
review/expiry date
elimination path or review trigger

DSM-EXC-003 — Exceptions Expire or Revalidate

Security exceptions SHOULD have an expiration date or mandatory revalidation trigger.

Permanent silent exceptions are prohibited.

DSM-EXC-004 — Elimination Path

Where an exception represents technical debt, the record SHOULD state what event could remove it.

Examples:

vendor adds OIDC
legacy database upgraded
application migrated
protocol retired
new platform capability delivered

---

26. Anti-Pattern Catalogue

DSM-AP-001 — Secrets in Git

Plaintext credentials committed to source control.

DSM-AP-002 — CI Variable as Universal Vault

The CI system becomes the indefinite organization-wide credential database.

DSM-AP-003 — Shared Production Account

Unrelated workloads share a single production identity.

DSM-AP-004 — Vault Token Beside Application

A permanent vault token is distributed to workloads to obtain other secrets.

The secret-zero problem has merely moved.

DSM-AP-005 — Eternal API Token

A third-party token has no owner, expiry expectation, rotation process, or revocation procedure.

DSM-AP-006 — Kubernetes as Universal Vault

All organizational credentials are replicated into Kubernetes regardless of need.

DSM-AP-007 — Human Rotation Ritual

Operators copy replacement credentials manually between multiple systems.

DSM-AP-008 — Rotation Without Adoption

The authority changes the credential but consumers retain the previous value.

DSM-AP-009 — Deleting the Leak

A credential is removed from Git or logs and considered trustworthy again without revocation.

DSM-AP-010 — Secret Scanning Without Response

Secret detection creates findings but no response mechanism exists.

DSM-AP-011 — Masked Means Safe

A credential is considered secure because CI log masking is enabled.

DSM-AP-012 — Developer Production Secret

Developers routinely retain production credentials locally.

DSM-AP-013 — Root Everywhere

The secrets broker uses broad producer authority where narrower delegation is practical.

DSM-AP-014 — One Credential Per Environment

All workloads in an environment receive the same shared secret.

DSM-AP-015 — Secrets Manager as Generic Database

The secrets platform becomes a generic configuration store, obscuring authority boundaries.

DSM-AP-016 — LLM Gatekeeper

An LLM independently decides whether secret-bearing authority may be issued.

DSM-AP-017 — Permanent Agent Authority

An autonomous agent receives broad standing credentials because future actions cannot be predicted.

DSM-AP-018 — Dynamic at Any Cost

A complex dynamic-credential architecture is introduced despite low-value credentials, poor target support, severe reliability issues, and no meaningful reduction in standing authority.

DSM-AP-019 — Undebuggable Federation

Identity failures are opaque, causing engineers to bypass workload identity using personal or static credentials.

DSM-AP-020 — Hidden Credential Through Tooling

An agent, script, or platform appears credentialless while one of its tools or intermediate services exercises broad persistent credentials on its behalf.

---

27. Maturity Model

Maturity SHOULD be assessed independently for:

1. individual credentials;
2. applications;
3. platforms;
4. organizational portfolios.

An organizational maturity level MUST NOT conceal lower-level exceptions.

Maturity levels describe dominant architectural practice, not the complete absence of lower-level mechanisms.

---

DSM-M0 — Scattered

Characteristics:

• credentials in source trees;
• local .env files;
• manually managed CI variables;
• shared accounts;
• unclear owners;
• inconsistent rotation.

M0 is non-conformant for security-significant production credentials.

---

DSM-M1 — Vaulted

Characteristics:

• secrets centralized;
• encrypted at rest;
• authenticated access;
• basic access control;
• reduced plaintext distribution.

The organization has solved primarily where secrets live.

---

DSM-M2 — Managed

Characteristics:

• documented lifecycle;
• rotation;
• secret detection;
• defined revocation;
• audit trails;
• break-glass procedures;
• orphan detection.

The organization manages secrets as governed assets.

---

DSM-M3 — Federated

Characteristics:

• workload identity established;
• OIDC/workload federation common;
• secret-zero patterns reduced;
• human and machine identities separated;
• new compatible workloads normally receive distinct machine identity.

The organization increasingly manages identities rather than passwords.

---

DSM-M4 — Ephemeral

Characteristics:

• dynamic database credentials;
• short-lived certificates;
• temporary cloud authorization;
• job-specific capabilities;
• automatic expiry;
• explicit leasing and revocation.

The organization manages temporary authority.

---

DSM-M5 — Capability Brokered

Characteristics:

• standing credentials minimized;
• workloads request capabilities rather than bags of secrets;
• authorization uses identity and context;
• high-value keys remain non-exportable where practical;
• agents receive per-operation or per-task authority;
• root credentials are highly isolated.

The organization primarily manages authority rather than secret material.

---

28. Minimum Viable Adoption Profile

The maturity model describes architectural evolution.

It is not necessary to reach M3–M5 before gaining substantial security value.

A team beginning at M0/M1 SHOULD first establish the following baseline.

DSM-CORE-1 — Minimum Viable Adoption

For security-significant production systems:

• no plaintext secrets in Git;
• one identifiable authority for each persistent secret;
• known owner;
• known consumers where practical;
• environment separation;
• defined revocation method;
• rotation policy;
• automated secret scanning;
• CI masking treated only as defense in depth;
• development credentials separated from production;
• explicit exceptions;
• workload federation preferred for new integrations when readily available.

This typically corresponds to a healthy M2 trajectory.

DSM-CORE-2 — Next Best Investment

After DSM-CORE-1, teams SHOULD prioritize elimination of the credentials with the highest combination of:

authority × lifetime × exposure × operational frequency

rather than attempting indiscriminate migration of every secret at once.

---

29. Measurement Model

Metrics SHOULD distinguish what can be measured directly from what requires cross-system inference.

29.1 Tier A — Authority-Native Metrics

Usually straightforward to instrument:

Metric	Target
Credentials with known owner	100%
Credentials with expiry metadata	↑
Rotation success rate	→ 100%
Credentials issued dynamically	↑
Credential TTL distribution	↓
Revocation events	observable
Failed issuance/renewal rate	low
Active leases	observable
Authentication failures	observable

29.2 Tier B — Cross-System Inventory Metrics

Require correlation between several systems:

Metric	Target
Credentials with identified consumers	100%
Shared production credentials	→ 0
Orphaned credentials	→ 0
Workloads using federation	↑
CI variables containing credentials	↓
Kubernetes Secret copies	↓ where avoidable
Static-to-ephemeral ratio	↓

29.3 Tier C — Exposure and Runtime Metrics

Often require advanced discovery or telemetry:

Metric	Target
Physical/logical copies per credential	↓
Effective standing authority	↓
Detection-to-revocation time	↓
Runtime credential exposure duration	↓
Unknown/unmanaged credential rate	→ 0

Tier C metrics SHOULD carry an explicit coverage or confidence indication.

A metric based on 60% discovery coverage MUST NOT be presented as complete estate knowledge.

---

30. Exposure Model

A useful conceptual risk proxy is:

Exposure Risk
    ∝
authority
× lifetime
× copies
× accessibility

Security controls therefore have four fundamental levers:

reduce authority
reduce lifetime
reduce copies
reduce eligible access

Standing authority is a particularly important combination of the first two dimensions: significant authority that remains continuously available creates exposure even while it is not actively being used.

The preference hierarchy in Section 5 is valuable precisely because movement upward usually reduces several exposure dimensions simultaneously.

Replacing a shared permanent cloud key with federated job identity, for example, can simultaneously reduce:

• scope;
• lifetime;
• copies;
• number of eligible consumers;
• standing authority.

---

31. Tool Mapping

The canon deliberately does not prescribe individual products.

Tools occupy architectural roles.

Tool / Class	Authority	Identity	Dynamic issuance	Rotation	Delivery	Detection	Crypto
OpenBao	✓	✓	✓	✓	✓	—	✓
HashiCorp Vault	✓	✓	✓	✓	✓	—	✓
GitLab Secrets Manager	✓	GitLab-native	partial	✓	✓	GitLab ecosystem	—
CI OIDC issuers	—	✓	via federation	—	—	—	—
AWS Secrets Manager	✓	IAM	target-dependent	✓	✓	—	KMS
AWS STS	—	✓	✓	n/a	✓	—	—
GCP Secret Manager	✓	IAM/WIF	target-dependent	✓	✓	—	KMS
GCP Workload Identity	—	✓	✓	n/a	✓	—	—
Azure Key Vault	✓	Entra	target-dependent	✓	✓	—	✓
SPIFFE/SPIRE	—	✓	identity issuance	automatic	✓	—	PKI
External Secrets Operator	—	workload	—	sync	✓	—	—
Secrets Store CSI	—	workload	—	refresh	✓	—	—
SOPS + age/KMS	encrypted state	key identity	—	external	GitOps	—	✓
Sealed Secrets	encrypted state	cluster	—	limited	GitOps	—	✓
Sigstore/Cosign	—	OIDC	signing identity	n/a	—	transparency	✓
HSM/KMS	key authority	IAM	operations	✓	API	audit	✓
Infisical	✓	✓	✓	✓	✓	integrations	varies
Akeyless	✓	✓	✓	✓	✓	integrations	✓
Doppler	✓	✓	target-dependent	✓	✓	integrations	—
CyberArk	✓	✓	✓	✓	✓	✓	integrations

Capability presence does not imply equivalent assurance, maturity, or suitability.

Tool capabilities also evolve independently of the canon. A tool mapping therefore SHOULD be treated as implementation guidance rather than a normative property of the canon.

---

32. Reference Architecture

A high-maturity implementation may resemble:

                    ┌───────────────────────┐
                    │ HUMAN IDENTITY        │
                    │ SSO / MFA / Hardware  │
                    └───────────┬───────────┘
                                │
                                ▼
┌────────────────────────────────────────────────────┐
│                 IDENTITY PLANE                     │
│                                                    │
│ CI OIDC │ Kubernetes │ SPIFFE │ Cloud Workload ID │
└───────────────────────┬────────────────────────────┘
                        │ identity assertion
                        ▼
┌────────────────────────────────────────────────────┐
│          POLICY / CAPABILITY CONTROL               │
│                                                    │
│ policy │ context │ least authority │ leases        │
└───────────────────────┬────────────────────────────┘
                        │
          ┌─────────────┴─────────────┐
          ▼                           ▼
┌──────────────────┐         ┌──────────────────────┐
│ SECRETS / CRED.  │         │ NATIVE IDENTITY     │
│ AUTHORITY        │         │ TARGET               │
│                  │         │                      │
│ KV / PKI / DB /  │         │ Cloud IAM / API     │
│ transit / lease  │         │ accepting federation│
└────────┬─────────┘         └──────────────────────┘
         │
         ▼
┌────────────────────────────────────────────────────┐
│ DELIVERY                                           │
│ Direct API │ Agent │ CSI │ ESO │ ephemeral file   │
└───────────────────────┬────────────────────────────┘
                        ▼
┌────────────────────────────────────────────────────┐
│ CONSUMERS                                          │
│ CI │ workloads │ services │ agents │ humans        │
└────────────────────────────────────────────────────┘


┌───────────────────────┐
│ ROOT OF TRUST         │
│ KMS │ HSM │ Root CA   │
│ quorum/recovery       │
└──────────┬────────────┘
           │ protects / anchors
           └──────────────► identity, policy and secret planes


All security-significant planes
            │
            ▼
┌────────────────────────────────────────────────────┐
│ INDEPENDENT AUDIT / SECURITY TELEMETRY             │
│ immutable or independently protected where needed  │
└────────────────────────────────────────────────────┘

The architecture explicitly permits two high-quality paths:

identity → native target

and:

identity → broker → issued capability → target

A broker SHOULD NOT be inserted merely because one exists.

In multi-region, multi-account, or multi-cluster environments, the boundaries between identity, authority, roots of trust, and independent audit SHOULD be modeled explicitly rather than assumed to be global.

---

33. CI Platform Mapping

The principles are CI-platform independent.

A modern CI environment SHOULD attempt:

job
 ↓
short-lived CI identity
 ↓
OIDC / federation
 ↓
target policy
 ↓
temporary capability

This pattern applies to:

• GitLab CI;
• GitHub Actions;
• cloud build platforms;
• self-hosted CI systems supporting OIDC or equivalent federation.

Stored CI variables remain appropriate for compatibility cases, but SHOULD be treated as the lower part of the preference hierarchy rather than the architectural default.

---

34. GitLab-Oriented Mapping

GitLab SHOULD be used as appropriate as:

• CI workload-identity issuer;
• repository policy boundary;
• workflow and deployment authority;
• secret-detection surface;
• project/group secret authority where useful.

GitLab Secrets Manager MAY be useful for:

• project-level static secrets;
• group-level secrets;
• credentials tightly coupled to GitLab authorization;
• targets incapable of dynamic issuance.

GitLab CI variables SHOULD NOT become:

• the organization-wide vault;
• the default location for cloud master credentials;
• the normal bootstrap mechanism for external secrets systems.

GitLab OIDC SHOULD be preferred where supported for:

GitLab → secrets authority
GitLab → cloud IAM
GitLab → deployment platform
GitLab → federated external service

---

35. OpenBao/Vault-Oriented Mapping

A general-purpose secrets authority can provide:

Secrets Authority
Credential Broker
Dynamic Credential Issuance
PKI
Cryptographic Transit
Lease Management
Revocation
Audit Source

It SHOULD NOT automatically become the location for every item of sensitive configuration merely because it can store arbitrary values.

The desired pattern remains:

identity
   ↓
policy
   ↓
specific capability

rather than:

application
   ↓
large bag of persistent secrets

---

36. Kubernetes-Oriented Mapping

A preferred decision path is:

Kubernetes workload
       │
       ▼
projected workload identity
       │
       ├──────────────► cloud/native federation ──► target
       │
       └──────────────► secrets authority
                               │
                               ├── dynamic credential
                               └── required static secret
                                       │
                                 ┌─────┴─────┐
                                 ▼           ▼
                             direct/CSI     ESO
                                             │
                                             ▼
                                      Kubernetes Secret

The shortest trustworthy path SHOULD generally be preferred.

---

37. Decision Procedure

Whenever a new credential is proposed, the designer SHOULD answer the following questions in order.

Q1 — Can the operation use identity directly?

If yes:

do not create a secret.

Q2 — Can the target accept federated identity?

If yes:

federate.

Q3 — Can the target issue an ephemeral credential?

If yes and operationally viable:

issue dynamically.

Q4 — Can an existing static credential be automatically rotated?

If yes:

manage and rotate it centrally.

Q5 — Must a persistent static credential exist?

If yes:

vault it and manage it explicitly.

Then determine:

Who owns it?
Who consumes it?
What authority does it grant?
How is it delivered?
How many known copies exist?
How is it rotated?
How is it revoked?
How is leakage detected?
How is use audited?
What happens if the issuer is unavailable?
When could this credential be eliminated?

This decision procedure is the minimum conceptual implementation of the canon.

---

38. Conformance

A system is Fully Canon Conformant when:

1. all applicable MUST requirements are satisfied; or
2. violations exist only as explicit DSM-EXC exceptions.

A declaration SHOULD take the form:

DevOps Secrets Management Canon v1.0

System: payment-platform
Adoption Profile: Full
Maturity: DSM-M4

Discovery Coverage:
  declared/inventory: 100%
  automated-discovery estimate: 87%
  runtime-discovery estimate: 65%

Exceptions:
  - EXC-042 legacy-bank-api-token
  - EXC-057 vendor-sftp-password

Discovery coverage SHOULD be included when materially incomplete discovery could affect the credibility of a maturity claim.

Teams not yet ready for full conformance MAY instead declare:

Adoption Profile: DSM-CORE-1

provided this is not represented as full canon conformance.

---

39. Portfolio Conformance

Organizations SHOULD NOT claim a single maturity level without describing the distribution of authorities or credentials.

A preferred representation is:

M0   0%
M1   4%
M2  11%
M3  27%
M4  46%
M5  12%

The distribution SHOULD ideally distinguish important credential classes.

For example:

Cloud workloads      M4
Database access      M4
Third-party SaaS     M2
Legacy appliances    M1
CI identity          M3
Signing              M5

Portfolio declarations SHOULD state material discovery limitations.

For example:

Coverage:
  managed authorities       98%
  CI systems                100%
  Kubernetes clusters        95%
  third-party SaaS           70%
  developer-held material    unknown

A maturity declaration describes what is known about the estate; it MUST NOT imply that unknown areas have been proven free of unmanaged credentials.

---

40. Non-Normative Framework Alignment

This section is informational and does not establish compliance.

The canon is broadly compatible with the direction of established security frameworks.

Zero Trust

The strongest alignment is with zero-trust architecture principles:

• authenticate explicitly;
• authorize per request;
• minimize implicit trust;
• limit standing privilege;
• use contextual policy;
• prefer short-lived credentials.

The M3–M5 progression can be seen as increasingly complete application of these ideas to machine and workload authority.

NIST Cybersecurity Framework

Relevant themes include:

• asset and identity awareness;
• access control;
• credential protection;
• continuous monitoring;
• detection;
• incident response;
• recovery.

The canon adds a more specific credential-lifecycle and workload-identity model beneath those higher-level outcomes.

NIST SP 800-53

The canon overlaps especially with control families concerned with:

• access control;
• identification and authentication;
• audit and accountability;
• configuration management;
• system and communications protection;
• incident response.

It should not be treated as a replacement for an SP 800-53 control assessment.

ISO/IEC 27001

Relevant areas include:

• identity management;
• authentication information;
• access rights;
• privileged access;
• cryptography;
• logging;
• secure development;
• configuration management;
• incident management.

The canon can provide an implementation-oriented secrets-management submodel beneath an ISO 27001 ISMS.

Compliance Principle

Compliance frameworks tend to ask:

Is credential risk controlled?

The canon additionally asks:

Why does this credential exist at all?

That second question is what drives movement from M2 toward M3–M5.

---

41. Governing Principles

The central design principle of this canon is:

A persistent secret represents deferred identity or capability engineering.

Sometimes that debt is rational.

Legacy systems exist. Third-party APIs expose fixed tokens. Recovery authorities cannot always be eliminated. Dynamic issuance can introduce real dependencies and operational cost.

The canon therefore does not demand maximal machinery.

Instead, every persistent secret should provoke these questions:

Why must this authority exist as a credential?
Why must the credential persist?
Why must its value be readable?
Why must it be copied?
Why must more than one principal possess it?
What prevents us from moving it one level upward in the preference hierarchy?

The desired long-term trajectory is:

secret storage
    ↓
secret lifecycle management
    ↓
workload identity
    ↓
ephemeral credentials
    ↓
capability brokerage

But the operational rule is:

Move authority upward only when the resulting system is both more secure and sustainably operable.

The end state of mature secrets management is not the elimination of every secret.

It is the transition from managing secret material to:

managing explicit, bounded, observable authority.