Entra migration review: prove client secrets are retired

A working managed identity or federated credential does not prove that the former client secret is retired. Review every deployed consumer and every customer-managed password credential within the declared scope. Record three distinct outcomes: credential retired, runtime migration complete, and exception open. Complete closure requires the first two, resolved residual-token exposure, and no open exception.

Microsoft recommends moving applications away from password- or certificate-based authentication toward managed identities and workload identity federation where supported. This is existing migration guidance, not a newly announced retirement deadline. The acceptance criteria below are this article’s proposed review procedure, not a Microsoft certification standard. Microsoft migration guidance

Define the scope and outcomes

An application object describes an application; a service principal represents it in a particular tenant. A managed identity is a special service principal whose credentials developers do not manage. These distinctions determine which objects and runtimes the review must cover. Workload identity overview

Write the claim before collecting evidence: “For the listed tenants, application and service-principal objects, all customer-managed password credentials formerly usable by the listed deployments are retired as of time T; every listed consumer now uses replacement method Y.” Identify production, staging, scheduled jobs, automation, recovery deployments, and any other consumers sharing those identities. Record resource targets and the expected replacement identity for each consumer.

Use these outcomes consistently:

A retired credential and an incomplete runtime migration can coexist. For example, a removed secret may still be referenced by a recovery deployment that will fail when started. Conversely, all runtimes may use federation while an unused but valid secret remains. Neither situation qualifies for complete closure.

Inventory both credential locations

Inspect passwordCredentials on the application object and every relevant service-principal object in the scoped tenants. An app-registration-only export is insufficient. Microsoft Graph exposes password credentials on both object types. Its service-principal reference documents the tenant-local object’s credential collection. servicePrincipal reference

For each entry, record tenant ID, object type, object ID, application/client ID, credential keyId, startDateTime, and endDateTime. Add the responsible owner, consumers, inventory timestamp, and change record. These credential fields describe identity and validity; a normal inventory cannot recover the original secret value.

Take before-and-after inventories. Remove customer-managed password credentials from their actual owning objects. Graph provides separate application removePassword and servicePrincipal removePassword operations, each identifying the credential by keyId. The service-principal operation is documented in the servicePrincipal removePassword reference. Retain the operation result and a subsequent inventory confirming absence. Remove expired entries as cleanup too; expiry alone is not the removal evidence required by this procedure.

Keep platform-managed identity credentials outside this deletion checklist. Managed-identity service principals cannot be modified directly like ordinary application service principals. Review the old customer-managed credentials and the replacement identity separately. servicePrincipal types

Prove the replacement method was exercised

During a controlled deployment window, explicitly select managed identity or federation. Disable credential-chain alternatives and legacy fallback for the test. Start with an isolated client or use the library’s supported cache-bypass mechanism. Require evidence that authentication actually occurred through the selected provider; restarting a process alone is not sufficient if another cache remains.

For federation, correlate the deployed provider configuration and trust metadata with a new assertion exchange. Preserve nonsecret evidence of the selected method, issuer, subject, audience, time, and request identifiers. For managed identity, record the selected identity and evidence that the runtime used the managed-identity provider. If platform caching prevents demonstrating fresh issuance, record that limitation and keep the fresh-authentication requirement unresolved. Never attach assertions or bearer tokens to the report.

Then correlate that authentication with the identity observed by the resource and successful required operations. The same service principal can authenticate through a secret or federation, so its application ID alone cannot identify the method. Likewise, a successful resource call using an old cached token does not exercise the replacement method. Microsoft documents the alternative credential flows and MSAL token-source diagnostics. Client credential flows, MSAL troubleshooting

Resource authorization remains a separate check. APIs using application permissions must validate required roles. ACL-based APIs can accept app-only tokens without roles, but must enforce their own authorization checks. Delegated scp claims do not replace app-only authorization. Microsoft’s API authorization models

Make the negative test reproducible

Under this article’s procedure, a negative test passes only when all of the following evidence agrees:

1. Establish provenance. Map the exact legacy secret-store version used by the deployment to its owning object and credential keyId, using provisioning and deployment records. Where authorized and still possible before removal, establish a fresh successful baseline with that same value and test harness. Do not recreate a deleted credential for testing. If the mapping or value is unavailable, record the test as unproven.
2. Validate the request. Use the correct tenant, client ID, resource, and endpoint for the environment. For the v2 endpoint, send a form-encoded request with grant_type=client_credentials, the resource’s /.default scope, and the correctly encoded secret value. A credential identifier is not its secret value. Token request specification
3. Request a new token after removal. Bypass token caches and confirm that a request reached Entra. The test necessarily sends the legacy credential directly to Entra over TLS. Prevent its disclosure through command history, request-body logging, diagnostic traces, reports, screenshots, or tickets.
4. Classify the rejection. Require a credential-related rejection consistent with removal, supported by the administrative evidence and verified request. A generic invalid_client result alone is insufficient. Wrong tenant/client, encoding mistakes, missing parameters, Conditional Access blocks, network errors, throttling, and resource authorization failures are inconclusive.
5. Preserve correlation. Retain the OAuth error, diagnostic error code, timestamp, correlation ID, request/trace ID where returned, credential metadata, harness version, and reviewer. Remove secret values while preserving the identifiers needed to connect the records.

Use Microsoft’s troubleshooting guidance to interpret the actual response; diagnostic codes can change and should not become a permanent numeric allowlist for automated closure. Confidential-client troubleshooting

A successful token response fails the retirement gate. A credential-related rejection without reliable provenance or removal evidence also fails the evidentiary gate. If testing cannot be completed safely, keep the exception open; do not preserve a usable secret indefinitely merely to obtain a test result.

Separate executable fallback from historical material

Review deployed configuration, secret-store references, CI/CD variables, infrastructure templates, schedulers, retry logic, and recovery runbooks. Include configuration precedence and environment-specific overrides. A dormant deployment that can still execute the old path is a fallback and blocks runtime completion.

An inert historical copy of an already retired credential is a cleanup finding, not evidence that authentication still works. Record where it exists, restrict access as appropriate, and prevent its restoration into executable configuration. Do not claim that repository scanning proves every copy has disappeared. Microsoft recommends secret scanning and push protection as continuing safeguards. Migration guidance

Resolve previously issued tokens

Deleting a credential must not be treated as immediate revocation of previously issued access tokens. Microsoft instructs clients to use returned lifetime information such as expires_in, rather than assume a fixed lifetime. Token lifetime guidance

For closure, document the last possible issuance time and a defensible expiry bound for each affected resource, accounting for applicable lifetime settings and clock tolerance. One observed token’s expiry does not bound every outstanding token. Close residual exposure only after the documented bound has passed or an applicable resource control demonstrably blocks those tokens. If neither can be established, leave an exception open. Monitoring supports this evidence; an arbitrary quiet observation period does not replace it.

Workload Conditional Access can block by location or risk for eligible single-tenant service principals registered in your tenant. It excludes managed identities and multitenant applications. Creating or modifying these policies requires Microsoft Entra Workload ID Premium licensing. Assign the service principal directly to the policy. These controls do not prove credential removal. Conditional Access scope and licensing

Workload CAE currently supports tenant-registered, single-tenant service principals accessing Microsoft Graph, excluding managed identities and third-party SaaS/multitenant apps. Clients must declare cp1 and handle claims challenges. Documented revocation events are service-principal disablement, deletion, and high risk; location and risk policy changes are also supported. Secret deletion is not a listed revocation event. Workload CAE documentation

Illustrative closure record

The following is a fictional evidence record, not a customer result. Short labels stand for full identifiers retained in the actual record.

If another credential, tenant, or consumer appears, extend the record and repeat the affected checks before closure. For an unresolved dependency, assign an owner and remediation date, restrict secret storage, and document rotation and monitoring. Approval acknowledges the exception; it does not convert it into completion.

These checks can form part of a broader Cloud Security assessment. The report must still limit its conclusion to the named objects, consumers, resources, and evidence date. It cannot establish that a secret was never copied or that unexamined environments are clear.

FAQ

Is deleting the Key Vault copy enough?

No. Verify removal from the owning Entra object, complete the credential-specific negative test, and inspect all scoped consumers. Storage cleanup, credential retirement, and runtime migration are separate checks.

Can we close when managed identity or federation works?

Only after fresh authentication proves the selected method, all scoped credentials satisfy the retirement procedure, every consumer has no executable legacy fallback, and residual-token exposure is resolved. An approved exception keeps complete closure open.

Does a failed request prove retirement?

Only a correctly constructed, fresh request using the verified legacy value, with a credential-related rejection correlated to removal evidence, satisfies this procedure. Unrelated failures are inconclusive.

Does an old secret in repository history block closure?

An inert copy of a demonstrably retired credential does not by itself block closure. Track cleanup separately. A valid credential or a deployment path capable of loading legacy configuration does block closure.

Further reading

• Active Directory security