Governing Application Identities in Entra ID: A Defensive Cybersecurity Maturity Model

Every organisation that runs workloads on the Microsoft identity platform accumulates application identities. App registrations, service principals, managed identities, and now agent identity blueprints. They multiply quietly, and most of them operate outside the controls that govern human users. No MFA challenge. No session lifetime. No conditional access policy unless someone deliberately builds one.

This is not a post about the dangers of app registration ownership. Others have written about that well, and the attack surface is real. What I want to address is the organisational problem that sits underneath: most enterprises have no coherent model for deciding how to govern application identities, who is responsible for each layer of that governance, and what controls should exist at each stage of maturity.

What follows is a five-stage defensive cybersecurity maturity model for application identity governance in Entra ID. It is designed for security leaders, identity engineers, and SOC teams who need to move beyond checkbox policies and toward something that actually reduces risk.

Why application identities need their own governance model

Human identity governance is a well-understood discipline. Most mature organisations have processes for joiner-mover-leaver, privileged access management, access reviews, and credential hygiene. Application identities receive almost none of that rigour.

The gap is structural, not accidental. Application identities were historically treated as infrastructure plumbing, something a developer configured once and rarely touched again. But the reality in a modern Entra ID tenant is different. Application identities now hold permissions that rival or exceed those of your most privileged administrators. They authenticate without interactive controls. They persist indefinitely unless someone actively decommissions them. And their credentials, client secrets and certificates, can be created by anyone with ownership rights and used from anywhere.

The defensive cybersecurity case is straightforward: if your threat model accounts for compromised administrator accounts but not compromised application identities, you have a blind spot. Application identities are a persistence mechanism, a lateral movement vector, and a privilege escalation path. They need a governance model built for that reality.

The following diagram illustrates how human identities and application identities differ in the controls applied to them. The gap on the right side is the problem this post addresses.

Understanding the attack surface

Before walking through the maturity model, it is worth grounding the discussion in what an attacker actually gains when they compromise an application identity or its governance controls.

Credential authority through ownership

An owner of an app registration can add client secrets, upload certificates, modify redirect URIs, assign users for SSO, add other owners, and change App Role Assignments. If the application holds high-impact application permissions like Directory.ReadWrite.All, User.ReadWrite.All, AppRoleAssignment.ReadWrite.All, or RoleManagement.ReadWrite.Directory, a new credential gives the holder the ability to authenticate as that application and exercise those permissions. No PIM activation, no MFA, no session controls.

This is the core problem: governance teams assign ownership as an accountability label, but Entra ID implements it as credential management authority. Those are fundamentally different things, and organisations that conflate them create unmonitored privilege paths.

Dual-object ownership

Ownership is not unified across the app registration and its service principal. Each is a separate Entra ID object with its own owner list. The app registration governs credentials, redirect URIs, and permission declarations. The service principal governs tenant-specific configuration: SSO settings, user assignments, conditional access targeting, and provisioning.

A compromised service principal owner can manipulate SSO configuration and user assignments. A compromised app registration owner can mint new credentials. Incident response that reviews only one misses half the exposure.

SSO as a high-value target

An app registration that serves as a SAML or OIDC identity provider for a downstream platform (your SIEM, your PAM solution, your ITSM tool) is a high-value target regardless of its API permissions. Control over that registration's redirect URIs and claims configuration is control over authentication to those platforms. An attacker does not need Directory.ReadWrite.All if they can redirect authentication tokens for your security tooling.

The agentic identity expansion

Microsoft Entra Agent ID introduces agent identity blueprints as a new identity construct for AI agents. These blueprints are application objects that hold credentials and acquire tokens on behalf of agent identities. Platforms like Copilot Studio, Azure AI Foundry, and Microsoft 365 Agent SDK are already creating these identities automatically. Every governance gap that exists for traditional app registrations will be inherited by agent identities, and at greater scale and speed.

The maturity model

This model has five stages. Each stage builds on the previous one, and covers more than Entra ID settings. Ownership models, operational workflows, and detective controls all change as you progress.

Most organisations are at Stage 1 or Stage 2. The largest drop in actual risk exposure happens between Stage 2 and Stage 3. Stage 5 is what it looks like when application identities are governed with the same discipline as privileged human identities.

Stage 1: Blind spots (no visibility)

Organisational posture: The organisation has no centralised inventory of application identities. App registrations are created by whoever needs them, often by developers with no oversight. Many registrations have no owner. Others have owners who left the organisation months or years ago. No one can answer basic questions: how many app registrations exist, which ones hold privileged permissions, and which ones have active credentials.

What is missing:

• No inventory of app registrations or service principals
• No classification of applications by risk or business criticality
• No monitoring of credential lifecycle events (creation, expiry, rotation)
• No connection between application identities and the security operations function

Defensive gaps: At this stage, application identities are invisible to the SOC. A compromised app registration with Directory.ReadWrite.All could be used for weeks or months without detection. There is no alerting, no baseline to detect anomalies against, and no runbook for application identity compromise.

How to know you are here: Run the following queries. If either number surprises you, or if you cannot run them at all, you are at Stage 1.

Find every app registration with no owner via Microsoft Graph:

GET https://graph.microsoft.com/v1.0/applications?$count=true&$filter=owners/$count eq 0&$select=id,displayName
ConsistencyLevel: eventual

Do the same for service principals with zero or only one owner:

GET https://graph.microsoft.com/v1.0/servicePrincipals?$count=true&$filter=owners/$count eq 0 or owners/$count eq 1&$select=id,displayName
ConsistencyLevel: eventual

In PowerShell:

Connect-MgGraph -Scopes "Application.Read.All"
 
# App registrations with no owner
Get-MgApplication -ConsistencyLevel eventual -Count appCount `
    -Filter "owners/`$count eq 0" -Select Id, DisplayName
Write-Host "Ownerless app registrations: $appCount"
 
# Service principals with no owner or only one
Get-MgServicePrincipal -ConsistencyLevel eventual -Count spCount `
    -Filter "owners/`$count eq 0 or owners/`$count eq 1" -Select Id, DisplayName
Write-Host "Service principals with 0-1 owners: $spCount"

Priority actions:

1. Build a complete inventory of app registrations and service principals, including their permission profiles, credential status, and current owners.
2. Identify every application with application-level permissions (type Role in requiredResourceAccess) and flag those holding high-impact permissions.
3. Identify every application configured as a SAML or OIDC identity provider for downstream platforms.
4. Establish a single point of accountability, even if informal, for application identity hygiene within the identity or security team.

Stage 2: Uniform policy (governance without risk context)

Organisational posture: The organisation has written an ownership policy. Every app registration is expected to have an owner. Owners are typically assigned based on who created the application or who submitted the request. The policy is applied uniformly regardless of what the application does or what permissions it holds.

This is where most organisations stop. It is also where the most dangerous assumptions live.

What exists:

• An ownership policy that requires every app registration to have an assigned owner
• Owners assigned uniformly, usually the requesting developer or team lead
• Basic lifecycle processes (e.g. ownership is reviewed when someone leaves)

What is missing:

• No differentiation between a low-privilege OIDC sign-in app and a highly privileged automation service
• No recognition that ownership grants credential management authority, not just accountability
• No monitoring of what owners actually do with their ownership rights
• No integration with the SOC or incident response processes

Defensive gaps: A standard user who owns a high-privilege app registration has, in effect, been granted unmonitored credential management authority over a privileged identity. If that user account is compromised through phishing, token theft, or session hijacking, the attacker can add a secret to the high-privilege app and maintain persistent access as the application. During incident response, the compromised user account will be the focus. The app registration ownership vector is unlikely to be investigated.

The organisation believes it has solved the governance problem. It has actually distributed privilege broadly without corresponding detective or preventive controls.

The following diagram shows the attack path that Stage 2 governance leaves open:

How to know you are here: You have an ownership policy, but it applies the same rules to every app registration. You cannot quickly identify which app registrations represent high-privilege identities, and you have no alerting on credential management events.

Identifying your high-risk ownership assignments:

Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"
 
$apps = Get-MgApplication -All -Property Id, DisplayName, AppId, RequiredResourceAccess
 
$results = foreach ($app in $apps) {
    $hasAppPermissions = $app.RequiredResourceAccess |
        ForEach-Object { $_.ResourceAccess } |
        Where-Object { $_.Type -eq "Role" }
 
    if ($hasAppPermissions) {
        $owners = Get-MgApplicationOwner -ApplicationId $app.Id
        if ($owners) {
            [PSCustomObject]@{
                DisplayName        = $app.DisplayName
                ApplicationId      = $app.AppId
                OwnerCount         = $owners.Count
                Owners             = ($owners.AdditionalProperties.userPrincipalName -join "; ")
                AppPermissionCount = ($hasAppPermissions | Measure-Object).Count
            }
        }
    }
}
 
$results | Format-Table -AutoSize

This script identifies every app registration that has application permissions (type Role in requiredResourceAccess) and lists their current owners. If any of those owners are standard user accounts without elevated privilege, you have a gap.

Priority actions:

1. Classify all app registrations into risk tiers based on their permission profile and SSO relationships (see Stage 3).
2. Begin monitoring the Add service principal credentials and Update application – Certificates and secrets management audit events in your SIEM.
3. Cross-reference your ownership list against your risk classification. Flag every instance where a standard user account owns a high-risk application.

Stage 3: Risk-differentiated controls (tiered governance)

Organisational posture: The organisation classifies app registrations by risk profile and applies different governance controls to each tier. Ownership policy, monitoring intensity, credential management processes, and incident response procedures all vary based on the tier.

This is the stage that actually changes your risk posture.

Risk tiering model:

Tier 1: Low risk. Delegated permissions only, with narrow scopes: User.Read, openid, profile, offline_access. The application acts within the signed-in user's context. Blast radius is limited to a single user session. Ownership by a standard user is appropriate. Quarterly review of permissions and credential status.

Tier 2: Moderate risk. Broader delegated permissions (e.g. Mail.ReadWrite, Files.ReadWrite.All) or a small number of low-sensitivity application permissions. Ownership is acceptable but should be restricted to users who have completed application governance training. Audit log monitoring should be active for credential management events on these applications. Credential rotation should follow a defined schedule. Semi-annual access review of owners and permissions.

Tier 3: High risk. Application permissions with high-impact scope: Directory.ReadWrite.All, User.ReadWrite.All, AppRoleAssignment.ReadWrite.All, RoleManagement.ReadWrite.Directory, Mail.Send (application context). Also includes any application serving as the SSO bridge for critical downstream platforms regardless of API permission profile. Ownership should be removed from standard users entirely or restricted to hardened administrative accounts subject to PIM, phishing-resistant MFA, and dedicated admin workstations.

Tier 4: Critical. Applications that underpin the organisation's security infrastructure: the SIEM integration, the identity provider federation, the PAM connector, the EDR management plane. These are treated as critical infrastructure. No standing ownership. Credential operations handled exclusively through controlled change management processes. Every configuration change logged, reviewed, and correlated by the SOC.

Defensive controls at this stage:

• SIEM alerting on credential creation, certificate upload, and redirect URI modification for Tier 3 and Tier 4 applications
• Owner changes on Tier 3/4 applications treated as security events requiring approval
• Conditional access policies targeting workload identities where supported
• Defined incident response runbooks that include application identity compromise scenarios
• SOC analysts trained to investigate app registration and service principal audit logs during incident triage

How to know you are here: You have a documented risk classification for your app registrations. Ownership policy varies by tier. You have active SIEM alerting on credential lifecycle events for high-risk applications. Your incident response playbooks include application identity compromise.

Priority actions to move forward:

1. Formally separate accountability metadata from credential management authority (see Stage 4).
2. Begin automating credential lifecycle management: rotation reminders, expiry alerting, and orphaned credential detection.
3. Establish a recurring cross-functional review cadence involving identity engineering, security operations, and application owners.

Stage 4: Separated accountability (decoupled governance)

Organisational posture: The organisation formally decouples accountability from credential authority. Entra ID ownership is no longer used as a governance mechanism for high-risk applications. Accountability is tracked through metadata that carries no privilege. Credential management is an operational function performed through controlled processes by appropriately privileged accounts.

The following diagram shows the separation of concerns at Stage 4:

How this works in practice:

Custom Security Attributes handle governance metadata. The organisation defines attributes for business owner, technical contact, cost centre, data classification, risk tier, last review date, and lifecycle status. These are assigned to the service principal and managed through the Entra admin centre, Graph API, or PowerShell. They provide full audit traceability without granting any credential management capability.

Custom Security Attributes require the Attribute Assignment Administrator role to assign and the Attribute Assignment Reader role to view. Critically, Global Administrator and other built-in admin roles do not have access to these attributes by default. This means governance metadata is isolated from operational controls, giving you a genuine separation of duties.

Ownership (the Entra ID capability) is reserved exclusively for accounts with appropriate privilege posture (PIM-eligible, phishing-resistant MFA, compliant device) and only where there is a genuine operational need. For Tier 3 and Tier 4 applications, the preferred state is no standing owner. Credential operations are performed by identity engineers through audited change management processes or automated entirely through workload identity federation and managed identities.

Defensive controls at this stage:

• The Add owner to application audit event is treated as a security signal for Tier 3/4 applications, triggering SOC investigation
• Credential creation on high-risk applications requires change management approval and is logged to the SIEM with full correlation
• Workload identity federation replaces client secrets wherever possible, eliminating long-lived credentials
• Managed identities are used for Azure-hosted workloads, removing the need for any credential stored in the app registration
• Regular automated scans detect drift: ownerless applications, applications with ownership that contradicts tier policy, expired or soon-to-expire credentials, and permissions that have expanded beyond baseline

How to know you are here: Accountability and credential authority are formally separated for all high-risk applications. Custom Security Attributes or equivalent metadata tracks governance information. Ownership changes on privileged applications are investigated by the SOC. You are actively reducing long-lived credentials through federation and managed identities.

Stage 5: Continuous defensive governance (fully integrated security posture)

Organisational posture: Application identity governance is fully integrated into the organisation's defensive cybersecurity operations. Application identities are treated as first-class entities in the threat model, the detection engineering programme, and the incident response framework. Governance is continuous, automated where possible, and subject to the same rigour as privileged human identity management.

What this looks like:

Detection engineering. The SOC has purpose-built detection rules for application identity abuse. These include: anomalous token acquisition patterns for high-privilege app identities, credential creation outside approved change windows, redirect URI modifications on SSO-configured applications, consent grant anomalies, and application permission changes that escalate an application's effective privilege. These detections are tested, tuned, and maintained as part of the organisation's detection engineering lifecycle, not static alerts written once and forgotten.

Threat modelling. Application identities are explicitly included in organisational threat models. Red team and purple team exercises include scenarios for app registration compromise, credential theft, and privilege escalation through application ownership. The results feed back into detection rule development and governance policy refinement.

Automated lifecycle governance. Application identity lifecycle is managed through automation: creation requires approval workflows tied to risk classification, credentials are rotated on schedule or replaced with federation, applications with no sign-in activity for a defined period are flagged for decommissioning, and ownership assignments are validated against tier policy continuously.

Agentic identity coverage. Agent identity blueprints created by Copilot Studio, Azure AI Foundry, and similar platforms are automatically ingested into the governance framework. They are classified, assigned governance metadata, and subjected to the same tiered controls as traditional app registrations. The organisation's governance model scales with the rate of identity creation, not against it.

Executive reporting. Security leadership receives regular reporting on application identity posture: total application count by tier, credential hygiene metrics, ownership compliance, detection coverage, and mean time to detect and respond to application identity incidents. Application identity risk is a standing item in the organisation's security governance forum.

How to know you are here: Application identity governance is indistinguishable in rigour from privileged human identity governance. Your SOC actively hunts for application identity abuse. Your red team tests it. Your detection engineering programme covers it. Your executive reporting tracks it. Governance scales automatically with new identity creation.

Mapping your position

Most organisations sit between Stage 1 and Stage 2. Getting to Stage 3 does not require new tooling. It requires a decision to stop treating all application identities the same.

Immediate actions regardless of stage

These five actions reduce risk now, wherever you sit on the model:

1. Alert on credential creation. Configure your SIEM to alert on Add service principal credentials and Update application – Certificates and secrets management audit events. This is the single highest-value detection for application identity abuse and can be implemented in an afternoon.

2. Audit both object types. Ownership on the app registration and the service principal are independent. Any access review or incident response that checks only one misses half the exposure.

3. Map your SSO-configured applications. Identify every app registration that serves as a SAML or OIDC identity provider for downstream platforms. These are high-value targets regardless of API permissions and should be governed at Tier 3 or above.

4. Classify before you assign. Before assigning an owner to any app registration, check its permission profile and SSO relationships. If it holds application permissions or bridges authentication to critical platforms, apply tiered controls.

5. Prepare for agentic scale. If your organisation is adopting any platform that creates agent identities, extend your governance framework to cover those identities from day one. Retrofitting governance after the fact is much harder.

Conclusion

Application identity governance is a defensive cybersecurity problem, not an IT administration chore. The identities in your tenant that operate with no MFA, no session controls, and no interactive oversight deserve governance that matches the risk they carry.

Most organisations will not reach Stage 5 overnight, and that is fine. Get to Stage 3. That is where the gap between policy and actual exposure closes most sharply.

The number of application identities in your tenant is about to grow fast. Agentic AI, automation pipelines, and continued migration into the Microsoft identity platform will push non-human identities past human identities in most tenants within a few years. Build governance that scales with that growth, and run it as a security programme.

If an application identity can act with tenant-wide authority, it belongs in your threat model, your detection programme, and your privilege governance framework. Defend it accordingly.