Refresh interval is the polling cadence ESO uses to check the external provider for secret changes. It is a governance setting as much as an operational one, because it determines how long a rotated credential can remain stale in the cluster before reconciliation updates it.
Expanded Definition
A refresh interval is the scheduled polling cadence an External Secrets Operator or similar controller uses to check an external provider for secret changes. It determines how quickly updated credentials, tokens, or certificates are reconciled into the cluster after rotation.
In NHI governance, this is not just an operational timer. It is a control boundary that affects stale secret exposure, blast radius after rotation, and how quickly revoked access stops working in practice. Short intervals improve freshness but increase provider load, API traffic, and reconciliation churn. Longer intervals reduce operational overhead but extend the window in which a compromised or expired secret can remain usable. The term is often discussed alongside secret rotation, reconciliation, and drift detection, but it is distinct from those outcomes because it governs when the system looks, not whether the provider has changed.
Definitions vary across vendors on whether refresh interval is fixed, per-secret, or policy-driven, so implementation details should be verified against the controller and vault integration in use. The most common misapplication is treating the refresh interval as a compliance checkbox, which occurs when teams set it once and do not align it with rotation cadence, token TTLs, or incident response requirements.
For broader identity governance context, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
Examples and Use Cases
Implementing refresh interval rigorously often introduces a freshness-versus-load tradeoff, requiring organisations to weigh faster secret reconciliation against higher polling volume and more frequent controller activity.
- A production database password rotates every 12 hours, and the refresh interval is set to 5 minutes so workloads pick up the new secret quickly after rotation.
- A low-risk internal API key is polled every 30 minutes because the provider rate limits frequent checks and the application can tolerate a longer staleness window.
- An incident response team temporarily reduces the refresh interval during a suspected secret leak so revoked credentials stop being used sooner after remediation.
- A cluster using an external secret store aligns refresh interval with certificate expiry monitoring to reduce the chance of expired TLS material remaining mounted.
These patterns are commonly discussed in operator guidance around secret lifecycle management, and they map directly to the lifecycle and visibility concerns described in the Ultimate Guide to NHIs. For implementation semantics and controller behavior, the NIST Cybersecurity Framework 2.0 supports the broader expectation that controls should be timely, monitored, and recoverable.
Why It Matters in NHI Security
Refresh interval matters because stale secrets are still live secrets. If polling is too slow, a rotated credential may continue to authenticate successfully long after the source of truth has changed, creating a gap between governance intent and actual enforcement. If polling is too aggressive, operational friction can hide the very control weaknesses teams are trying to reduce.
This is especially important in environments with large service-account sprawl. NHI Mgmt Group notes that 71% of NHIs are not rotated within recommended time frames, and that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. Those figures show why refresh timing cannot be treated as an incidental implementation detail. It directly affects how quickly the organisation can contain exposure after rotation, revocation, or compromise.
The term also becomes relevant in Zero Trust and incident response, where validation must be continuous enough to keep pace with change. Organisations typically encounter the consequences only after a leaked secret, failed revocation, or expired certificate remains usable in production, at which point refresh interval becomes operationally unavoidable to address.
For NHI governance and risk reduction, the Ultimate Guide to NHIs provides the baseline research context, while the NIST Cybersecurity Framework 2.0 reinforces the need for monitored, timely control execution.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Refresh cadence affects secret freshness and exposure windows in external secret management. |
| NIST CSF 2.0 | PR.AC-1 | Timely credential updates support access control integrity and reduce stale authorization. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on continuously current identity and credential state. |
Tune refresh intervals so updated secrets propagate fast enough to preserve valid access control.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
