Entra ID Service Principal Hidden Credentials: The Secrets Your Portal Does Not Show You

The App Registration object (Microsoft.Graph.Application) is the canonical definition of a custom application in your tenant. When you add a client secret under App Registrations > Certificates and Secrets, you are adding it to the Application object. The service principal object (Microsoft.Graph.ServicePrincipal) is a separate object -- the local instantiation of the application in this tenant. For applications registered in other tenants (third-party SaaS, partner apps) or first-party Microsoft apps, there is no App Registration in your tenant -- only the service principal. Both the Application object (via POST /applications/{id}/addPassword) and the ServicePrincipal object (via POST /servicePrincipals/{id}/addPassword) accept credentials independently. The portal's App Registrations blade only shows Application object credentials. The Enterprise Applications blade shows the service principal but provides no credentials UI. Result: any credential added to a ServicePrincipal object is portal-invisible.

Using the Microsoft Graph PowerShell SDK: Connect-MgGraph -Scopes 'Application.Read.All'. Get all service principals with non-empty credential sets: Get-MgServicePrincipal -All | Where-Object { ($.PasswordCredentials.Count -gt 0) -or ($.KeyCredentials.Count -gt 0) } | Select-Object DisplayName, AppId, @{N='Secrets';E={$.PasswordCredentials.Count}}, @{N='Certs';E={$.KeyCredentials.Count}}, @{N='SecretExpiry';E={($.PasswordCredentials | Sort-Object EndDateTime -Descending | Select-Object -First 1).EndDateTime}}. This returns every SP across your tenant -- including Microsoft first-party apps -- that holds credentials. For each result: DisplayName tells you which app, SecretExpiry tells you when the credential expires. A first-party Microsoft app (DisplayName like 'Microsoft Graph', 'Office 365 SharePoint Online', 'Device Registration Service') with a non-Microsoft-issued credential is a red flag. Separately query App Registrations: Get-MgApplication -All | Where-Object { ($.PasswordCredentials.Count -gt 0) -or ($_.KeyCredentials.Count -gt 0) } | Select-Object DisplayName, AppId. Compare the two lists -- SPs with credentials that have no corresponding App Registration in your tenant (they belong to another tenant or are first-party) are the ones invisible in the portal.

The Entra ID audit log records credential additions to both Application and ServicePrincipal objects but categorizes them differently. Event: Update service principal -- Additional Details: operation type 'Add service principal credentials'. Search the Entra ID audit log: In Entra admin center > Monitoring > Audit logs > Service = Application Management > Activity = 'Update service principal' > filter for 'credentials' in the Details. Alternatively in Sentinel: AuditLogs | where OperationName == 'Update service principal' | where TargetResources[0].modifiedProperties has 'KeyDescription' | project TimeGenerated, InitiatedBy, TargetResources[0].displayName, Result. Alert on: credential additions to any first-party Microsoft SP (the DisplayName will match a known Microsoft application), credential additions during off-hours, credential additions by non-automated identities (a human admin adding a secret to a Microsoft SP is highly unusual), and credentials with unusually long lifetimes (1-2 years -- attackers prefer long-lived secrets for persistence). In MDI and Defender XDR: the 'Application credential modification' detection type covers some of these patterns.

Beyond hidden credentials, audit for these dangerous SP credential patterns. Over-permissioned SPs with active secrets: a service principal that holds credentials and is assigned a sensitive role (Global Admin, Exchange Admin, Application Admin) can be used by anyone who knows those credentials to authenticate as the application and use its permissions -- without any MFA requirement, because service principals are excluded from user-targeted MFA Conditional Access policies. Find them: Get-MgServicePrincipal -All | ForEach-Object { $sp = $; Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id | Where-Object { $.AppId -eq '00000003-0000-0000-c000-000000000000' } | ForEach-Object { [PSCustomObject]@{ SP = $sp.DisplayName; Role = $.PrincipalDisplayName; Credentials = $sp.PasswordCredentials.Count } } } | Where-Object { $.Credentials -gt 0 }. Additionally, check for SPs with Directory Roles: Get-MgDirectoryRoleMember -All (across all roles) and cross-reference against the SP credential list. Any SP with both active credentials and a privileged directory role assignment is a persistence risk if the credentials are leaked or attacker-added.

After auditing, enforce the minimal credential footprint. Remove unnecessary SP credentials: for each SP with credentials that you cannot attribute to a current business need, remove them. For App Registration credentials: navigate to App Registrations > the app > Certificates and Secrets > delete expired or unrecognized secrets. For SP-level credentials (via API): Remove-MgServicePrincipalPassword -ServicePrincipalId [spId] -KeyId [credentialId]. Prefer managed identities over SP credentials: for Azure workloads, use managed identities (which have no exportable credentials) instead of SP client secrets. For third-party SaaS integrations: prefer federated identity credentials (workload identity federation) over client secrets where the SaaS supports it -- federated credentials do not use a shared secret at all. Create a credential inventory policy: require all SP credentials to be documented in your identity inventory, with an owner, an expiry no longer than 90 days, and a rotation process. Use Azure Policy or custom scripts to alert on credential additions without an associated change ticket.