How to detect new credentials added to an app registration: Entra audit events, rules and response

An attacker who can add a client secret or certificate to an existing Entra ID application inherits every permission that application already holds, and the new credential keeps working after the original foothold is closed. MITRE ATT&CK describes this as adding credentials to service principals and applications "in addition to existing legitimate credentials", and it was a signature of the SolarWinds-era intrusions into Microsoft 365 tenants. This guide shows how to detect it: which audit events record a new secret, certificate or federated credential, how to parse them, which combinations separate a planned rotation from persistence, how to tie the new key to the sign-ins that use it, and how to respond. It is for SOC analysts, detection engineers and Entra application administrators. Managing secrets and their expiry is covered in the Azure Entra Client Secrets Security Guide; this page is about catching the credential nobody planned.

Key takeaways

• Three audit operations carry the signal: "Update application - Certificates and secrets management" on the app registration, "Add service principal credentials" on the enterprise application, and "Add service principal" when a credential arrives with a new principal. Microsoft's own Sentinel rules match all three.
• The service principal path is the stealthy one: credentials added directly to a service principal often do not appear in the portal's Certificates and secrets blade, so only the audit log and a Graph sweep show them.
• Every credential has a key ID: the audit event's KeyIdentifier matches ServicePrincipalCredentialKeyId in service principal sign-in logs, so you can prove whether the new key has been used, from where and against which resource.
• Context decides severity: a credential added outside a change window, by someone who is not an owner, to an app with high-privilege permissions, or to an app that previously had no credential, is the alert. Planned rotations are not.
• Prevent the multi-tenant variant: app instance property lock stops credentials being added to your app's service principal in other tenants; Microsoft states it has been enabled by default for new applications since June 2026.

When you need this

• After any admin account compromise: an Application Administrator or Cloud Application Administrator can add credentials to almost any app. Adding one to an app that already holds Mail.Read or Directory.ReadWrite.All application permissions is faster and quieter than creating a new app.
• Apps with owners outside IT: app owners, including non-admin members, can add passwords to apps they own. A compromised owner account is enough.
• Privileged automation identities: an application holding Application.ReadWrite.OwnedBy or Application.ReadWrite.All can add credentials through Microsoft Graph, so one leaked secret can be used to mint more.
• Vendor and SaaS integrations: the Commvault Metallic incident exposed Microsoft 365 app secrets held by a vendor; customers then had to know which credentials existed and whether they had been used. See the Commvault Metallic Breach 2025.

Before you start

• Collect: Entra audit logs (AuditLogs) and service principal sign-ins (AADServicePrincipalSignInLogs) into the SIEM. Without the second table you can see a key being added but not whether it was used.
• Read the property: credential details sit in TargetResources[].modifiedProperties under the display name KeyDescription, with old and new values as lists of entries containing KeyIdentifier=, KeyType=, KeyUsage= and DisplayName=.
• Test: add a secret and a certificate to a test app registration and a secret to a test service principal, then confirm all three events arrive and parse. Remove them afterwards and confirm the removals are logged too.
• Know your privileged apps: export application permissions (app role assignments) for every service principal so rules can raise severity for apps holding high-impact permissions. See How to find expiring app secrets and certificates in Entra ID for an export of every existing credential.

Step-by-step

1. Filter the operations. Match OperationName containing "Certificates and secrets management" or "Add service principal" with Result == "success", as Microsoft's "New access credential added to Application or Service Principal" rule does.
2. Diff the key lists. Parse KeyDescription old and new values and take the set difference, so a single event that lists every existing key yields only the new one.
3. Extract key ID, type, usage and display name. Keep KeyUsage Verify (credentials used to authenticate the app); Sign is for SAML token signing and needs its own review.
4. Enrich with the initiating user or app, IP, user agent, the app's owners, its application permissions and whether a change ticket exists.
5. Correlate with sign-ins: look up the new key ID in ServicePrincipalCredentialKeyId over the following days.
6. Run in report mode for two weeks, label each hit, then promote the High rules to paging.

A starting query, adapted from Microsoft's published Sentinel rule:

AuditLogs
| where OperationName has_any ("Add service principal", "Certificates and secrets management")
| where Result =~ "success"
| mv-apply T = TargetResources on (where T.type in~ ("Application", "ServicePrincipal")
    | extend TargetName = tostring(T.displayName), TargetId = tostring(T.id),
             TargetType = tostring(T.type), Props = T.modifiedProperties)
| mv-apply P = Props on (where P.displayName =~ "KeyDescription"
    | extend NewKeys = parse_json(tostring(P.newValue)), OldKeys = parse_json(tostring(P.oldValue)))
| extend Added = set_difference(NewKeys, OldKeys)
| where array_length(Added) > 0
| mv-expand Added
| parse tostring(Added) with * "KeyIdentifier=" KeyId ",KeyType=" KeyType ",KeyUsage=" KeyUsage ",DisplayName=" KeyName "]" *
| extend Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
         ActorIP = coalesce(tostring(InitiatedBy.user.ipAddress), tostring(InitiatedBy.app.ipAddress)),
         FirstCredential = (tostring(OldKeys) == "[]")
| project TimeGenerated, OperationName, Actor, ActorIP, TargetType, TargetName, TargetId,
    KeyId, KeyType, KeyUsage, KeyName, FirstCredential, CorrelationId

Microsoft's rules filter on application targets by default and note the filter can be widened to service principals; the version above includes both. Then join the output on KeyId to AADServicePrincipalSignInLogs on ServicePrincipalCredentialKeyId to list every sign-in made with the new credential. The KQL for Threat Hunting Guide explains the operators.

Detection rules

Sweep existing credentials

Rules only see new events within your log retention. Credentials added before that are still valid.

1. Export passwordCredentials and keyCredentials from every application and every service principal with Microsoft Graph, keeping keyId, displayName, startDateTime and endDateTime. The hint field holds the first three characters of a secret and helps match it to a stored value without exposing it.
2. Flag credentials on service principals of apps registered in your own tenant (usually unnecessary), credentials whose start date falls in a period of known compromise, and apps with more credentials than their owners can explain.
3. Join each keyId to the last 30 to 90 days of service principal sign-ins. A credential that is used but that nobody claims is an incident; one that is unused is a removal candidate.
4. Ask each owner to confirm every credential. Owners who cannot are a governance finding in their own right.

Triage a hit

• Was it planned? Check the change ticket and ask the app owner through a channel the actor cannot see.
• Who added it? Review the actor's sign-ins in the hours before: risky sign-in, new location, MFA method change or role activation. See How to Detect MFA Method Registration Abuse.
• Has it been used? Sign-ins with the key ID, their IPs, resources and results.
• What can the app reach? Application permissions, directory roles, Azure RBAC assignments and mailbox access policies.
• What else changed? New owners, new permissions, redirect URI changes or consents on the same app in the same window. See How to detect OAuth consent phishing in Entra ID.

Respond to a rogue credential

1. Preserve: export the audit entries, the app and service principal objects and the related sign-ins.
2. Remove the credential by key ID from the application or service principal (portal for app registrations; Graph removePassword or removeKey, or the matching PowerShell cmdlets, for service principal credentials).
3. Contain the app if it was used: disable the service principal while you investigate, and review what it accessed through the resource logs for each resource in its sign-ins.
4. Contain the actor: revoke sessions, reset credentials and remove unexpected app ownership or admin roles from the account that added the key.
5. Rotate the legitimate credentials on the same app if there is any chance they were read. See How to rotate Entra app secrets without downtime.
6. Hunt across the tenant for the same actor, IP or user agent adding keys elsewhere.

Rollback: if the credential turns out to be legitimate and was removed, the owner issues a new one through the normal change process; never restore the removed secret, and record the key ID so the rule can suppress that rotation pattern.

Reduce the attack surface

• Small organisations: deploy the first-credential, privileged-app and service principal rules, run the sweep quarterly, and keep application administrator roles to two or three people.
• Large organisations: drive severity from an app criticality table, require change tickets for credentials on tier 0 apps, automate owner confirmation and run the sweep monthly.

Verify it worked

• Replay: add a secret to a test app holding a harmless application permission, sign in with it from an unusual network, and confirm both the credential rule and the "new key used from new place" rule fire.
• Removal: after response, re-list the app's credentials and confirm the key ID is gone and no sign-in with it has succeeded since.

Measures that show it is working

• Percentage of credential additions matched to a change ticket.
• Median time from credential addition to owner confirmation.
• Number of credentials on service principals of first-party apps, trending down.
• Number of apps still using client secrets rather than certificates or federation.
• Credentials found by the sweep with no owner confirmation.

Common failure patterns

• Watching only app registrations: the service principal path is where the stealthy credentials go.
• Alerting on every rotation: without change context the rule is muted within a week. Enrich, then alert on the exceptions.
• Not linking to sign-ins: without the key ID join, responders cannot say whether the credential was used, which drives the whole scope of the incident.
• Removing the key but not the actor: the admin account that added it will add another.
• Ignoring legacy apps: forgotten OAuth applications with broad permissions are ideal hosts for a new credential, as the Microsoft Midnight Blizzard intrusion showed. See the Microsoft Midnight Blizzard Breach 2024.

Framework mapping

Practitioner checklist

• Stream Entra audit logs and service principal sign-in logs to the SIEM.
• Parse KeyDescription and diff old and new key lists for applications and service principals.
• Alert on first credentials, credentials on privileged apps and on service principals, and bursts.
• Join new key IDs to ServicePrincipalCredentialKeyId and alert on first use from new networks.
• Sweep all existing credentials and get owner confirmation for each.
• Respond in order: preserve, remove the key, contain the app, contain the actor, rotate, hunt.
• Enable app instance property lock on multi-tenant apps and reduce application administrators.
• Move workloads from secrets to certificates or workload identity federation.

Standards and references

• MITRE ATT&CK: Account Manipulation: Additional Cloud Credentials (T1098.001)
• Microsoft: Azure Sentinel Microsoft Entra ID analytic rules
• Microsoft Learn: AADServicePrincipalSignInLogs table reference
• Microsoft Learn: Configure app instance property lock
• Microsoft Learn: application addPassword (Microsoft Graph)
• Microsoft Learn: passwordCredential resource type (Microsoft Graph)

Related NHI Mgmt Group resources: Azure Entra Client Secrets Security Guide · How to audit Entra workload identity federated credentials · Entra ID Sign-In and Audit Log Detection Guide · MITRE ATT&CK T1098 Account Manipulation Guide