A rolling update is a deployment method that replaces application instances gradually rather than all at once. In Kubernetes, this helps teams introduce new versions while keeping the service available and limiting disruption. It is commonly used when change risk must be controlled and downtime is not acceptable.
Expanded Definition
A rolling update is a deployment pattern that shifts a workload from one version to another in controlled batches, so some instances remain live while others are replaced. In containerised environments and orchestration platforms, this approach is used to preserve availability, reduce blast radius, and observe the new release before full cutover. The key distinction is that a rolling update changes production gradually rather than through a single replacement event, which makes rollback and health checks central to the process.
Definitions vary slightly across platforms because implementation details differ, but the security meaning is consistent: change is introduced incrementally, with attention to service continuity and operational visibility. For teams managing internet-facing services, this pattern also supports safer recovery when application behaviour is uncertain after release. The NIST Cybersecurity Framework 2.0 reinforces the broader governance expectation that change should be managed to protect availability and resilience. The most common misapplication is treating a rolling update as inherently safe, which occurs when teams skip readiness checks and assume gradual replacement alone prevents service degradation.
Examples and Use Cases
Implementing a rolling update rigorously often introduces temporary version skew, requiring organisations to weigh continuity benefits against the operational complexity of mixed-instance states.
- Replacing pods in a Kubernetes deployment one set at a time while verifying application health before each next batch.
- Upgrading a customer portal behind a load balancer so users continue to receive service during the release window.
- Deploying a security agent or sidecar update gradually to confirm that telemetry, policy enforcement, and startup behaviour remain stable.
- Rolling out a backend API version while keeping older and newer instances compatible during the transition period.
- Using staged replacement to reduce the chance that a bad build will take down all replicas at once, especially in high-availability systems.
For operators who need a formal resilience lens, the NIST framework page above is useful for connecting deployment practice to broader availability and recovery expectations. In practice, rolling updates are most effective when paired with automated health probes, defined rollback criteria, and version compatibility testing across dependent services.
Why It Matters for Security Teams
Rolling updates matter because availability, integrity, and change control are security concerns, not just release engineering concerns. A poorly managed rollout can expose partial functionality, authentication failures, logging gaps, or inconsistent policy enforcement across replicas. That matters when security controls depend on uniform behaviour across the fleet, including secrets handling, API authorisation, and agent or service identity checks. In modern identity-heavy environments, a phased deployment can also reveal whether a workload depends on short-lived tokens, certificate rotation, or non-human identity bindings that were not fully tested before production change.
Security teams should care about the operational state during the rollout, not only the final version after deployment completes. If rollback is not tested, a failed update can leave systems in an uncertain intermediate state where incident response becomes slower and more error-prone. The same is true for controls that depend on continuous logging or enforcement at every instance. Organisations typically encounter the true cost of a rolling update only after a release causes partial outage or control failure, at which point staged replacement becomes operationally unavoidable to stabilise the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Change management and maintenance practices govern controlled deployment updates. |
| NIST Zero Trust (SP 800-207) | SA-4 | Zero trust architecture expects system changes to preserve policy enforcement during transitions. |
Use documented change control so rolling updates preserve availability and recovery options.
Related resources from NHI Mgmt Group
- What should organisations check before rolling out zero standing privilege at scale?
- What should IAM teams do before rolling out biometrics more broadly?
- Who is accountable when weak authentication remains in place after a regulatory update?
- What breaks when cloud identities can create, update, and delete the same workload service?
