Rotate Entra application certificates with proof of adoption

A renewed certificate can leave the application unchanged

Entra application certificate rotation is complete when the required clients can authenticate with the replacement credential and the old credential has been retired under an explicit acceptance decision. A new certificate in a vault is only one intermediate state. The application registration, certificate store, identity library and running process can each point at a different version. Treat those states separately before removing the key on which an overlooked worker still depends. ^[1][5][6]

Consider a hypothetical service with an API pool, a scheduled reporting job and a recovery deployment. The API canary obtains a token with a new certificate, so the release is marked successful. The reporting job runs less often and still selects the previous certificate; the recovery deployment has not started since the change. Removing the old credential can therefore expose a failure that the canary never exercised. This example illustrates a coverage problem, not a reported incident or a measured failure rate.

This guide concerns certificates used to authenticate an Entra application at a token endpoint. It does not cover renewal of a server's HTTPS certificate. Those workflows can share a certificate store while having different consumers, trust decisions and completion tests. Client authentication also remains separate from application consent and resource permissions. Successfully presenting a certificate does not grant a service every operation it might request. ^[7][8]

Begin by deciding whether the application still needs a stored certificate. Microsoft documents federated credentials as another application authentication option. A suitable runtime identity may remove a private-key distribution problem, but only when the source and target trust requirements fit the workload. Do not combine a certificate rotation with an unplanned authentication architecture migration. If a certificate remains the chosen mechanism, use the overlap and evidence procedure below to make its replacement observable. ^[4]

Follow the credential from registration to process

Build an inventory that connects the Entra application to each component that can request tokens. Include interactive services, background workers, scheduled jobs, administrative utilities and recovery instances. For each component, identify the application registration, resource it calls, library used for authentication, certificate lookup mechanism and deployment owner. A service name alone is not enough when several independently deployed processes use the same application identity.

The keyCredential resource supplies identifiers and validity information for a registered application key. Its keyId is distinct from a certificate-store version and from the application identifier. Keep those identifiers mapped in the rotation record so an operator can explain which registered credential a client is intended to use. Do not infer deployment adoption from a keyCredential start or end time; those fields describe credential metadata, not the state of a running process. ^[6]

Then inspect how the client finds its certificate. Microsoft.Identity.Web documents several certificate sources and supports multiple certificate descriptions for rotation. Its documented selection behavior matters when more than one candidate is configured. A replacement that exists later in a configured list may not be the certificate currently selected. Review the exact library configuration and version instead of assuming that the newest certificate in a store automatically wins. ^[1]

Azure Key Vault renewal introduces a related distinction. Renewing a certificate creates another version of the object, and a version-independent reference can identify the current object. That does not establish when an application resolves the reference, whether it caches the result or whether another deployment uses a version-specific identifier. Map the vault identifier, retrieved version and registered public key as separate evidence. A successful renewal event is not a fleet adoption report. ^[5]

Keep private material out of the inventory. The record should contain safe identifiers, validity dates, owners and references to approved storage locations. It should not contain a private key, access token or client assertion. If telemetry will report the selected credential, decide which non-secret identifier is useful and how it maps back to the rotation record. This makes a later failure diagnosable without turning the evidence system into another credential repository.

Identify which directory object the management operation changes. The application registration and its service principal are related but distinct objects, and the Graph application addKey reference describes an operation on an application. A runbook should name the intended object and authorized API path instead of using the word application for every directory record. Confirm the target identifier from the approved inventory before mutation, especially when several environments use similar display names. A familiar name is not evidence that the selected object owns the credential being rotated. ^[2][6][7]

Add the replacement through the right authorization path

The replacement needs to be registered before clients depend on it. Entra application credential management stores the public certificate information used to validate the client's proof, while the application retains access to the corresponding private key. Use a maintained identity library for assertion creation. Microsoft's current certificate-credential documentation specifies the supported assertion format, including signing and certificate-thumbprint fields; an old hand-written JWT example is not a dependable rotation procedure. ^[4][8]

Graph's application addKey operation has a particular authorization contract. It requires proof signed with an existing valid application key and is not the bootstrap path for an application with no valid certificate. This matters during an expired-all-keys incident: the ordinary rotation call cannot be assumed to repair the very proof on which that call depends. Use the authorized application-update or credential-management path appropriate to the application's state, with the required permissions and an accountable operator. ^[2][4]

Keep the proof of possession distinct from the client assertion used to obtain an access token. Both can involve signed JWTs, but they are different messages with different recipients and validation rules. Do not copy one into the other workflow or reuse token material as an audit artifact. The Graph API reference and the identity platform's certificate-credential reference should govern their respective operations. The article's acceptance procedure does not replace either protocol contract. ^[2][8]

Add the public replacement credential without discarding unrelated entries. When a management path updates a collection of key credentials, understand whether the operation is additive or replaces the supplied collection. Preserve other approved credentials and their identifiers. A rotation intended for one workload should not silently remove a separate worker's key or a credential retained for a documented recovery purpose. Review the proposed mutation against the inventory before sending it.

Define the overlap in terms of dependencies rather than a universal number of hours. The interval must account for deployment rollout, infrequently running clients, token caching, permitted rollback and the old certificate's remaining validity. Microsoft.Identity.Web's support for overlapping certificates enables a staged transition, but it does not choose the organization's release schedule. If a required job will not run before the old credential expires, arrange an authorized fresh-authentication test or explicitly change the deployment plan. ^[1]

There are also three different time concepts in this workflow. The certificate has validity metadata, the signed client assertion has its own short validity interval, and the returned access token has a separate expiration. Extending or replacing one does not automatically change the others. Microsoft's certificate-credential guidance recommends short assertions, while keyCredential records the registered key's validity fields. Preserve those meanings in diagnostics: an assertion-time failure should not be reported as proof that the replacement certificate itself has expired, and a valid certificate does not make an expired assertion acceptable. Use the maintained library's supported time handling rather than inventing a custom long-lived assertion to hide refresh failures. ^[6][8]

Prove fresh-token acquisition during overlap

A resource request made with a cached access token does not prove that the replacement certificate can authenticate. The test must exercise fresh token acquisition using the intended credential selection path. Otherwise, a canary can continue working with an earlier token while the new certificate is missing, mismatched or inaccessible. Separate token acquisition from the subsequent resource operation in the test record so their results remain interpretable. ^[1][7]

Begin with a controlled client instance that represents the real deployment configuration. Confirm that it can access the replacement private key through the approved mechanism, that the matching public credential is registered, and that the selected identity library can obtain a token. Record a non-secret credential identifier and the outcome. Avoid disabling caches globally in production just to make a test easier; use a supported test path or a scoped instance whose behavior is understood.

Next, perform a permitted operation against the target resource. This checks a different boundary. The token endpoint may authenticate the application while the resource still rejects the requested operation because of its audience, permissions or local policy. Conversely, a successful resource operation with an old cached token says little about the replacement certificate. A useful acceptance record connects the intended signing credential, fresh token request and narrowly scoped resource check without storing the token itself. ^[7]

Expand the evidence to every required instance class. The hypothetical reporting job needs a test even if it shares source code with the API, because its deployment configuration and run schedule can differ. A recovery deployment may use an older configuration artifact or a separately provisioned vault reference. The inventory determines the coverage. A count of successful API requests is not a substitute for identifying the clients that can still request tokens with the old key.

Make evidence gaps explicit. If the library does not expose a trustworthy selected-key identifier, do not invent a universal Entra log field that solves the problem. Combine the available configuration, controlled token acquisition and instance-specific observations, and state what remains uncertain. The required evidence depends on the implementation. The aim is a defensible adoption decision, not a claim that every platform supplies the same telemetry.

The before-and-after comparison in this section shows the intended change in operating practice. The earlier state treats renewal and one successful canary as completion. The proposed state retains overlap while each required consumer supplies fresh-authentication evidence. Neither side represents a measured deployment. The value of the comparison is the missing gate it makes visible: the old key remains necessary until the relevant consumers have actually moved.

Source. Microsoft.Identity.Web certificate authentication ^[1]; Azure Key Vault certificate renewal ^[5]; Graph keyCredential resource ^[6]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 1 accessible table

Boundary	Before	After
Certificate storage	Renewal produces a new stored version	Stored version is mapped to the intended keyId
Client deployment	One canary succeeds while other instances may remain stale	Every required instance class proves fresh-token acquisition
Retirement	Old key is deleted on a calendar date	Old key is retired after recorded adoption and rollback decisions

Figure 1 accessible table

Boundary	Before	After
Certificate storage	Renewal produces a new stored version	Stored version is mapped to the intended keyId
Client deployment	One canary succeeds while other instances may remain stale	Every required instance class proves fresh-token acquisition
Retirement	Old key is deleted on a calendar date	Old key is retired after recorded adoption and rollback decisions

Download imageDownload table CSV

Retire the old key without erasing rollback evidence

Retirement should be a separate action with a named owner. Before proceeding, review the adoption record, unresolved clients, remaining certificate validity and the permitted rollback path. If an old application release still selects only the old credential, removing that key changes the rollback contract. Decide whether to update the rollback configuration, close that rollback option or postpone retirement while the dependency is addressed. Do not leave the limitation hidden behind a familiar deployment rollback command.

Graph removeKey targets a particular keyId and has its own documented proof and permission requirements. Use the operation for the intended credential rather than treating retirement as deletion of an entire credential collection. Retain the old identifier and the authorized action record after removal so later authentication failures can be correlated with the change. The record should explain what was removed, when it was removed and why the adoption gate was considered complete. ^[3]

Where authorized and safe, perform a controlled fresh-authentication attempt using the retired credential and confirm that it is rejected. This tests the credential-removal boundary. It does not establish that every access token issued earlier has immediately stopped working. Entra's client credentials flow separates client authentication at token issuance from the resource's later handling of an access token. Keep those observations distinct when the rotation is part of incident containment. ^[7][8]

Also confirm that intended clients continue to obtain fresh tokens with the replacement. A successful negative test against the old key is not enough if retirement accidentally removed or misconfigured the replacement as well. Test the permitted path and the denied path separately, with the same disciplined handling of identifiers and token material. Capture failures before retrying with a different identity so the evidence does not conceal a configuration error.

An emergency replacement after suspected private-key exposure may require a different balance between overlap and availability. The organization may choose to retire the exposed credential before every consumer has migrated, accepting a controlled outage to reduce continued use of that credential. Label that as an incident decision with its own authority and evidence requirements. The ordinary rollout procedure should not imply that overlap is always appropriate when the old key is no longer trusted.

Source. Microsoft.Identity.Web certificate authentication ^[1]; Graph application addKey ^[2]; Graph application removeKey ^[3]; Entra client credentials flow ^[7]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 2 accessible table

Step	Actor	Required evidence	Boundary
Stage	Credential owner and Graph	Replacement public key and keyId registered	No private-key upload
Select	Client instance	Replacement signing credential selected	Separate from token cache
Authenticate	Token endpoint	Fresh token acquired	Separate from resource access
Authorize	Target resource	Permitted test operation succeeds	Existing resource grant
Retire	Credential owner	Specific old keyId removed	After adoption gate
Verify	Controlled test client	Old-key fresh authentication fails	Does not prove issued tokens vanished

Figure 2 accessible table

Step	Actor	Required evidence	Boundary
Stage	Credential owner and Graph	Replacement public key and keyId registered	No private-key upload
Select	Client instance	Replacement signing credential selected	Separate from token cache
Authenticate	Token endpoint	Fresh token acquired	Separate from resource access
Authorize	Target resource	Permitted test operation succeeds	Existing resource grant
Retire	Credential owner	Specific old keyId removed	After adoption gate
Verify	Controlled test client	Old-key fresh authentication fails	Does not prove issued tokens vanished

Download imageDownload table CSV

Leave a rotation record that can be repeated

The finished record should connect the replacement keyId, certificate-store version, validity dates, deployment inventory and fresh-authentication evidence. Include the old key's retirement action and any remaining access-token or rollback limitations. Those fields let the next operator distinguish a credential problem from a resource-permission problem without reconstructing the change from scattered logs. Keep identifiers consistent across the application owner, credential owner and deployment system.

Schedule the next review from the actual certificate lifecycle and the organization's release constraints. Also revisit the procedure when the identity library, certificate source, application topology or token acquisition path changes. A move from startup-only certificate loading to a different lookup mechanism changes what adoption evidence means. The previous test record remains useful history, but it does not automatically validate the new implementation. ^[1][5]

Use the evidence to improve the inventory. An overlooked scheduled job is a concrete missing consumer, not a reason to add vague instructions to be more careful. Add that job's owner, configuration source and test path to the next rotation. A library-selection surprise should produce an explicit configuration check. This keeps the process grounded in observable dependencies instead of turning it into a larger checklist with no connection to how the application runs.

The closing question is whether the organization can explain which credential each required client uses to obtain its next token. A renewed certificate answers where new material exists. A completed rotation additionally answers which consumers adopted it, which old credential was retired and what access or rollback state remains outside that retirement action. That is the evidence needed to make the next certificate change predictable.