Envoy Secret Discovery Service is a mechanism for delivering secrets and other configuration data to Envoy proxies at runtime from an external control plane. It lets a proxy fetch certificates, keys and related values over a managed channel instead of storing them locally in static files.
What Envoy Secret Discovery Service Does
Envoy Secret Discovery Service, often called SDS, is the runtime control path that delivers secrets and related configuration to Envoy proxies from a separate control plane. That design keeps certificates, keys, and similar material out of static local files and lets operators update sensitive values without rebuilding or redeploying the proxy.
SDS is important because the secret itself is part of the proxy’s trust boundary. If the channel, control plane, or secret source is weak, the proxy may authenticate with stale, exposed, or untrusted material even though the application traffic path still appears healthy.
Why Runtime Secret Delivery Matters
Compared with baked-in files, runtime delivery reduces the need to place long-lived credentials on disk or image layers. It also supports shorter rotation cycles, tighter scoping, and more consistent rollout across many proxies, which matters in service meshes and other distributed environments where configuration drift is common.
This is why SDS is usually discussed alongside secret management rather than simple configuration loading. The goal is not just convenience, but control over when secrets appear, how they are refreshed, and which component is trusted to supply them.
For a broader view of the design trade-offs around centralising and rotating secrets, see the Secrets Management Guide.
Secret Delivery Patterns and Operational Trade-Offs
SDS is typically used when proxies need certificates for mutual TLS, keys for upstream authentication, or other sensitive values that should not be copied into static configuration. That makes the control plane a high-value component, because it becomes responsible for distributing material that directly affects identity, encryption, and trust decisions.
The trade-off is clear: centralised delivery improves manageability, but it also concentrates responsibility. Operators must design for channel protection, secret freshness, source authenticity, and failure handling, because a broken or delayed update can affect proxy trust at scale.
If you need the adjacent identity model for certificates, tokens, rotation, and secret handling, the Ultimate Guide to NHIs, Static vs Dynamic Secrets gives useful context on why dynamic delivery is often preferred over long-lived material.
How Teams Validate and Govern SDS
Teams usually validate SDS by asking where the proxy receives its secrets, how the control plane is authenticated, whether delivery is encrypted in transit, and whether secret updates are observable. They also check whether proxies can continue operating safely if the control plane is delayed or unavailable, because availability and trust are tightly linked in runtime secret delivery.
Governance is about ownership as much as technology. Someone must define who can publish secrets, who approves certificate material, how expiry is monitored, and what happens when a secret is revoked or rotated unexpectedly. Without that discipline, SDS can become another fast path for secret sprawl instead of a control that reduces it.
For secret inventory and lifecycle ownership, the Service Account Inventory Template is a useful companion for tracking what needs to be rotated, reviewed, and assigned.
Risk and Threat Considerations
SDS concentrates trust in the delivery path, so compromise of the control plane, transport, or secret source can expose certificates and keys at scale. It also creates a tempting target for attackers who want to replace trusted material, intercept runtime updates, or force proxies to continue using stale secrets.
Failure mechanism: A weakly protected SDS channel, mis-scoped control plane access, or poor secret lifecycle handling can let an attacker steal, substitute, or stale-out proxy secrets without touching the application code.
Impact: The result can be proxy impersonation, broken mutual TLS trust, service disruption, lateral movement, or widespread credential rotation after compromise.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SDS delivers and rotates authenticators and related secret material. |
| IA-9 — Service Identification and Authentication | SDS commonly supplies service credentials and certificates to Envoy proxies. | |
| AC-6 — Least Privilege | SDS should restrict who can publish or retrieve secret material. | |
| Recommendation — Manage proxy secrets with IA-5 controls for creation, rotation, revocation, and storage. Use IA-9 to authenticate services and proxies that exchange runtime secret material. Apply AC-6 to limit which components can request, publish, or read proxy secrets. | ||
| CIS Controls v8 | CIS-5 — Account Management | SDS depends on tight control of secret-bearing accounts and rotation. |
| Recommendation — Use CIS-5 to inventory and govern accounts that can issue or consume SDS secrets. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | SDS is a runtime secret delivery pattern and must prevent exposed credentials. |
| Recommendation — Prevent secret leakage by avoiding static storage and enforcing protected delivery paths. | ||
Practitioner Guidance
Why practitioners should care: SDS is only as strong as the control plane and secret lifecycle behind it. Treat the delivery path as production security infrastructure, not as a convenience feature, because it governs the material that establishes proxy trust.
What to watch for: Watch for overly broad publishing rights, unexpected secret refresh patterns, missing expiry visibility, and proxies that silently depend on long-lived fallback material. Those conditions often point to drift between intended rotation policy and what is actually in use.
Practitioner takeaway: Use SDS to reduce static secret exposure, but pair it with strict source authentication, short-lived material where possible, and clear ownership for rotation and revocation.
Related resources from NHI Mgmt Group
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org