Which Certificate or Secret Is Your Entra App Actually Using? A Practical PowerShell Approach

One of the less glamorous parts of Microsoft Entra ID administration is dealing with app registrations that nobody seems to own anymore.

You know the pattern. An alert shows up because a certificate or client secret is about to expire. The app has three old credentials, two newer ones, no obvious owner, and no documentation worth the name. Removing the wrong one could break a production process. Leaving everything in place just adds to the mess.

That raises two very practical questions:

1. Is this application credential still being used at all?
2. If it is, can we identify which certificate or secret is actually being used in sign-ins?

Microsoft Entra sign-in logs can help answer both. The sign-in resource includes fields such as servicePrincipalCredentialKeyId and servicePrincipalCredentialThumbprint, and Microsoft’s own credential renewal guidance recommends validating new credentials in sign-in logs by checking the Key ID or thumbprint after rotation.

That is the use case behind the script in this post.

The Real-World Problem

In many environments, app registrations outlive their original owners.

A project ends. A developer changes teams. An integration is moved to a different platform. Months later, the app still exists, the automation still runs somewhere, and the only visible sign of life is an expiring certificate or secret in Entra ID.

At that point, the portal tells you what credentials exist, but not always what is actively being used. You might see:

• multiple certificates
• multiple client secrets
• overlapping validity periods
• generic display names
• no application owner
• no clue which server, script, or workflow is behind the authentication

That makes credential cleanup and rotation harder than it should be.

What the Script Does

The script takes a simple approach:

• reads certificates and client secrets from the target app registration
• pulls service principal sign-in logs for the app
• tries to correlate sign-in events with individual credential Key IDs
• shows either:

The preferred match is an exact comparison against servicePrincipalCredentialKeyId. If that field is not present in a sign-in event, the script can fall back to a safe JSON search for the selected GUID. That is admittedly a fallback rather than the ideal path, but it helps when sign-in records are not as complete as you would like.

To avoid overstating confidence, the output is split into two groups:

• VerifiedHits: events with enough useful attribution data to treat as meaningful
• SuspectMatches: events where the GUID matched, but the event is too sparse to treat as a strong result

That distinction matters, because not every sign-in record is equally helpful when you are trying to prove whether a credential is truly in use.

Why This Is Useful

This is most useful in three scenarios.

Expiring credentials with no clear owner

This is the big one. You get a certificate or secret expiry alert, but nobody knows whether the credential is still active. The script helps you determine whether that specific Key ID appears in recent service principal sign-ins.

Credential rotation

Microsoft recommends validating newly added credentials using sign-in logs before removing the old one. This script gives you a practical way to do exactly that by focusing on the Key ID of the new certificate or secret.

Cleanup and hardening

Some older app registrations accumulate stale credentials over time. Before cleaning them up, it helps to know which ones are active and which ones appear to be dead weight.

How the Matching Works

The logic is intentionally simple.

First, the script reads the app registration and builds an inventory of:

• certificates from keyCredentials
• client secrets from passwordCredentials

Then it queries sign-in logs for that application and tries to match each event to a credential.

The primary match uses:

• servicePrincipalCredentialKeyId

That field is documented in the Microsoft Graph signIn resource and represents the unique identifier of the key credential used by the service principal to authenticate. The same resource also documents servicePrincipalCredentialThumbprint, which is especially useful for certificate-based authentication. In practice, this means you can correlate a certificate or secret Key ID from the app registration with what shows up in sign-in logs.

A Note on Sign-In Log Data

There is one important caveat.

The script relies on service principal sign-in records being detailed enough to support correlation. In most useful cases they are, but not every event is equally rich. That is why the script does not pretend every GUID match is equally trustworthy.

If an event includes timestamp, IP, resource, or status data, it becomes a VerifiedHit. If the GUID match is present but the rest of the record is thin, the script treats it as a SuspectMatch instead.

That is a small design choice, but it makes the output more honest.

Example Usage

Overview mode

This shows all certificates and secrets for the application, together with observed usage in the selected window.

Drill down into a specific certificate

Drill down into a specific secret

What You Can Learn From the Output

A good overview run can quickly tell you:

• which credentials have recent activity
• which ones appear inactive
• which IP address is most commonly associated with a credential
• whether authentication attempts are succeeding or failing
• whether a credential rotation has actually taken effect

A drill-down run is even more useful when you are trying to answer the inevitable question:

“Can we remove this one yet?”

If a credential shows no verified activity in a meaningful time window, that does not automatically prove it is unused forever. But it gives you a much better starting point than guessing from the portal alone.

Why I Like This Approach

What I like about this method is that it bridges the awkward gap between Entra administration and application ownership.

The Entra admin often sees the expiring secret or certificate. The application owner, if one still exists, knows the business process. But when ownership is unclear, you need something objective. Sign-in logs, Key IDs, and a small amount of PowerShell can get you surprisingly far.

It is not magic. It will not tell you the full architecture of the forgotten integration or name the server running the code. But it can often tell you whether a specific certificate or secret is still active, and that alone can save a lot of time and avoid a lot of unnecessary risk.

Final Thoughts

If you manage enough app registrations, you will eventually run into credentials that are expiring without a clear owner, a clear source, or a clear retirement plan. That is exactly where this script helps.

Instead of treating every old certificate or secret as a blind risk, you can start by asking a better question: do we have evidence that this credential is still being used? Sometimes the answer is yes. Sometimes it is no. Either way, that is a much better place to start.

Script Source

Complete script as always is available for download on Azure365Addict GitHub.
Feel free to customize the script to fit your specific needs and improve your Microsoft Entra application hygiene.

If you have any questions or want to extend this into automated reporting or credential rotation validation, feel free to reach out.

Happy scripting!