# Do not assume every Service Fabric node retains the same old certificates

> Certificate rotation through the Key Vault VM extension can leave different certificate histories on existing and newly added nodes.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:21+00:00
- Modified: 2026-09-10T02:08:04+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Certificate rotation through the Key Vault VM extension can leave different certificate histories on existing and newly added nodes.

## Potentially affected

Service Fabric clusters provisioning certificates through the Key Vault VM extension.

## DSE recommendation

Compare certificate inventories across existing, newly scaled and reimaged nodes before relying on an older certificate.

## Article

## Source facts

The Key Vault VM extension retrieves and installs the current certificate version without removing existing certificates. Older versions can therefore remain on an existing node while a newly added scale-set node receives only the current version. Reimaging resets the store to the operating-system image and implicitly removes the earlier versions.

Service Fabric itself does not delete a user-declared certificate. For certificates provisioned as VM or scale-set secrets, deleting the referenced vault item or disabling its referenced version can make later deployments fail. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/cluster-security-certificate-management).

## Applicability

Identify the provisioning mechanism for each certificate before applying these behaviors. Do not infer a node’s certificate history from a successful cluster-wide rotation status or assume a particular reimaging schedule.

## DSE recommendation

DSE recommends including both long-lived and newly created nodes in certificate dependency reviews. If an application still needs an earlier certificate, investigate that dependency explicitly rather than relying on its accidental persistence. Keep cleanup decisions separate from rotation completion and review deployment references before changing vault items.

## Verification

Compare certificate identifiers and required application access on representative existing, scale-out and reimaged test nodes. Check the current deployment declarations alongside the inventories. Record which version each workload actually needs without collecting private keys. Approve cleanup only after the relevant owners have resolved dependencies and tested the intended lifecycle; finding an old certificate on one machine is not evidence that it will survive replacement elsewhere.

## Official references

[Microsoft Learn: Manage certificates in a Service Fabric cluster](https://learn.microsoft.com/en-us/azure/service-fabric/cluster-security-certificate-management). Source retrieved September 9, 2026.

## Primary reference

- Name: Manage certificates in a Service Fabric cluster - Azure Service Fabric | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/service-fabric/cluster-security-certificate-management
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not assume every Service Fabric node retains the same old certificates,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.