Teams should keep secrets only where the platform cannot issue direct trust relationships or where cross-platform federation is not yet supported. In those cases, the secret should be treated as an exception with stronger vaulting, tighter ownership, and faster rotation. Secretless should be the default target, not the universal assumption.
When secrets are still the right exception
Secretless is the right default when a platform can establish trust directly, but many real environments still have seams where that is not possible. The decision is usually driven by whether the target system supports federation, workload identity, mTLS, or another direct trust mechanism, not by whether a team prefers a cleaner architecture. When those options are missing, a secret can remain the least bad bridge.
That exception should be narrow. A secret is justified when it is the only practical way to reach a legacy system, a third-party API, or a cross-platform integration that cannot yet participate in trust federation. In that case, the team is not choosing secrets as the destination, only as a temporary control boundary while the integration path matures.
Teams should also distinguish between a durable exception and an avoidable one. If the platform can issue short-lived credentials, signed assertions, or federated access, then a persistent shared secret is usually a design smell rather than a requirement. For secret handling patterns and the move toward secretless workload identity, see the Secrets Management Guide and the static vs dynamic secrets guidance.
What makes a secret an acceptable fallback
An acceptable fallback secret has a clear owner, a documented purpose, and a bounded blast radius. It should exist because the receiving system cannot yet trust the caller directly, not because teams have not finished the integration work. That usually means the secret is tied to one service, one environment, and one specific path, rather than being reused across multiple workflows.
The strongest cases are legacy applications, vendor integrations, and systems that do not support modern federation. In those situations, the secret is a compatibility layer. It should not be treated like a permanent credential model, because the longer it lives, the more it starts to behave like one.
There is a practical difference between “secret required” and “secret convenient.” If the platform can use a direct trust relationship, the secret should be removed. If it cannot, the secret should be managed as a controlled exception with explicit expiry expectations and a plan to replace it. The NHI Authentication Guide explains the common direct-authentication alternatives that should be considered first.
For teams comparing implementation paths, the Secrets Management Buyer's Guide helps separate truly necessary vault-backed exceptions from cases where federation or platform-native identity is already available.
How to treat exceptions so they do not become the norm
Once a secret is accepted, the control objective changes from “avoid secrets” to “minimise the damage secrets can do.” That means vaulting, scoped ownership, rotation discipline, and rapid revocation must be mandatory, not optional. It also means every exception needs a named owner who can answer why the secret still exists and what would remove it.
Operationally, the right question is not whether a secret is present, but whether it is constrained. Is it short-lived where possible, isolated to one workload or vendor, and monitored for use and abuse? If the answer is no, the exception is already too broad. Teams that are still handling API credentials should use the API Key Management Guide to set rotation, scoping, and revocation expectations.
Broader patterns matter too. secrets sprawl, hardcoded credentials, and cross-environment reuse are what turn a temporary exception into a systemic weakness. The Guide to the Secret Sprawl Challenge is useful because it focuses on the failure mode teams most often inherit: secrets kept long after the original justification has vanished.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secrets and fallback credentials are central to deciding when to keep them. |
| NHI-07 — Long-Lived Secrets | The question contrasts secretless with exceptions that should not become persistent. | |
| NHI-05 — Overprivileged NHI | Any retained secret should be tightly scoped and not grant broad access. | |
| Recommendation — Vault retained secrets, rotate them quickly, and reduce exposure paths. Replace long-lived secrets with short-lived credentials wherever direct trust exists. Scope retained credentials to the minimum access needed and remove excess privilege. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Kept secrets still need lifecycle controls for issuance, rotation, and revocation. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Cross-platform and third-party integrations often rely on non-organizational authentication paths. | |
| AC-6 — Least Privilege | Exception secrets should be narrowly scoped to reduce blast radius. | |
| Recommendation — Manage secret lifecycle with rotation, revocation, and secure storage controls. Use stronger federation or trust-based authentication for external and workload access. Limit each retained secret to the minimum permissions required for its function. | ||
Practitioner Guidance
What to prioritise: Classify every secret as a temporary compatibility exception or a justified long-term dependency. If the owner cannot explain why direct trust is unavailable, treat the secret as remediable debt, not an accepted design choice.
Decision rule: If a platform can issue federation, workload identity, or signed assertions, move to that model. Keep a secret only when the receiving system cannot yet consume direct trust and the exception is explicitly bounded.
What to verify: Confirm that each remaining secret has one owner, one purpose, one environment, and a rotation path that is actually exercised. If any of those are missing, the secret is already operating as uncontrolled access material.
Common mistake: Teams often treat “we need a secret today” as proof that they need it forever. The safer interpretation is usually the opposite, the secret is a marker that the platform integration is incomplete.
Practitioner takeaway: Secretless should be the target state, and any retained secret should survive only as a tightly governed bridge with an explicit removal plan.
Related resources from NHI Mgmt Group
- How should teams reduce the risk from exposed NHI secrets?
- What breaks when teams keep rotating secrets instead of changing the access model?
- What breaks when teams keep privileged secrets scattered across users and browsers instead of a central vault?
- How should development teams keep secrets out of code while still enabling automation across build and deployment workflows?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org