Skip to main content
AppAlert

Which Entra app credential is this workload using?

How to see which secret or certificate key id an Entra workload still presents, in the portal or with a Log Analytics query, before you remove the old one.

Reviewed

On this page

Short answer: Check service principal sign-in logs. The field you want is ServicePrincipalCredentialKeyId. For certificates, also check ServicePrincipalCredentialThumbprint when it is present. Interactive user sign-in logs will not show which app secret or certificate a workload presented.

After you rotate a credential, expiry tracking does not prove the workload uses the replacement. You still need evidence from fresh, successful sign-ins for every consumer before you remove the old secret or certificate.

Why the wrong log hides the answer

Service principal sign-ins are requests where an app authenticates with its own credential, such as a client secret or a certificate. Microsoft documents this in the service principal sign-in logs overview.

User sign-in logs cover people signing in. They are the wrong place when you need the key id a workload still presents.

Portal path

  1. Open the Microsoft Entra admin center.
  2. Go to Identity, then Monitoring & health, then Sign-in logs.
  3. Open the Service principal sign-ins view.
  4. Find the service principal for the workload. Filter by application or service principal id when the list is long.
  5. Open a recent successful sign-in and read the credential key id on the event. Match that value to the Key ID on the app registration under Certificates & secrets.

Microsoft groups similar service principal sign-ins into one row when name or id, status, IP address, and resource match. Expand the row if you need the individual timestamps. Aggregation does not remove the credential key id from the underlying events, but it can make a busy app look quieter than it is until you expand the group.

Code path in Log Analytics

These fields live in the AADServicePrincipalSignInLogs table. Microsoft lists them in the AADServicePrincipalSignInLogs reference. The logs must already flow into a Log Analytics workspace. If the table is empty, check diagnostic settings, the selected workspace, the time range, and whether the workload has authenticated recently. The query below cannot recover history that was never collected. Missing events or an empty key id are not proof that the old credential is unused.

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ServicePrincipalId == "<service-principal-object-id>"
| project
    TimeGenerated,
    ServicePrincipalId,
    ServicePrincipalName,
    ServicePrincipalCredentialKeyId,
    ServicePrincipalCredentialThumbprint,
    ClientCredentialType,
    ResultType,
    ResourceDisplayName
| order by TimeGenerated desc

Replace <service-principal-object-id> with the object id of the service principal. Keep ResultType in the projection so you can tell success from failure while you watch for the new key id.

To list credential key id metadata without reading secret values, open the app registration Certificates & secrets page and copy each Key ID, display name, and expiry. Those values identify the credential. They are not the secret string. In Microsoft Graph, list passwordCredentials and keyCredentials on the application. You get keyId, display name, and dates. You do not get the secret value back.

Safe rotation order

  1. Add the new secret or certificate on the app registration.
  2. Update every workload that uses the old credential, including apps, jobs, and secret stores.
  3. Force a fresh token. Restart the process, clear the cached token, or wait until the current access token expires, then trigger a new request.
  4. Confirm a fresh, successful sign-in with the new key id for every consumer and resource you need to verify. One successful sign-in does not prove that other jobs or application instances have moved.
  5. Remove the old credential only after every consumer is confirmed, including scheduled jobs that may not have run yet. If the key id is missing or the logs cannot distinguish consumers, keep the overlap and obtain additional evidence from each workload.

This matches the renewal guidance for expired client secrets: confirm every consumer has moved before you remove the old secret. See Client secret expired and Client authentication certificate expired.

Common traps

Token cache. The workload may keep using a token minted with the old credential until that token expires. A config change alone is not proof. Force a new authentication and check the logs again.

Wrong log type. Searching interactive or non-interactive user sign-ins will not show ServicePrincipalCredentialKeyId. Stay on service principal sign-ins or AADServicePrincipalSignInLogs.

Deleting the old key too early. Adding a replacement does not update the workload. If you delete the old key before every consumer presents the new key id, the next authentication can fail.

AppAlert can watch expiry and send a notification when a credential is approaching end of life. That helps you start rotation on time. It does not show which key id a workload presented at sign-in. Use the portal or Log Analytics steps above for that proof.

Next: Expiry notifications from Microsoft →