I have been involved in enough Entra ID governance projects to know how the conversation about app registration ownership usually goes. Someone raises the point that every application should have an owner. The room agrees. A policy gets written. Owners get assigned. Everyone moves on believing the problem is solved.
It is not.
The problem is not that organisations assign owners. The problem is that they assign owners uniformly, without considering what ownership actually grants, and without differentiating between an app registration that handles basic OIDC sign-in and one that holds tenant-wide application permissions. Those two things carry fundamentally different risk profiles, and treating them the same is where governance quietly breaks down.
This post is not a warning about the dangers of app registration ownership. That ground has been covered well elsewhere. This is a practical framework for deciding when ownership is appropriate, when it is not, and how your approach should evolve as your tenant matures.
What Ownership Actually Grants
Before building a maturity model, it is worth restating what ownership means inside Entra ID, because it is frequently misunderstood.
An owner of an app registration can add client secrets, upload certificates, and modify redirect URIs. That is not an accountability tag. That is operational control over the application's authentication surface.
If the application holds high-impact application permissions such as Directory.ReadWrite.All, User.ReadWrite.All, or AppRoleAssignment.ReadWrite.All, a new credential created by an owner allows whoever possesses that credential to authenticate as the application and exercise those permissions directly. No PIM activation. No MFA challenge. No session controls.
This is the fundamental disconnect: governance teams treat ownership as accountability, but Entra treats it as credential management authority. Those are not the same thing, and conflating them creates risk.
Ownership Differs Between the App Registration and the Service Principal
Something that catches even experienced administrators off guard is that ownership is not unified across the app registration and its corresponding service principal. They are separate objects in Entra ID, and each maintains its own owner list independently.
The app registration defines the application's identity configuration globally: its credentials, redirect URIs, and required permissions. The service principal (enterprise application) represents how that application operates within your specific tenant, including SSO configuration, user assignments, and conditional access policy targeting.
An owner on the app registration can add secrets and certificates. An owner on the service principal can manage tenant-specific configuration such as SSO settings, user and group assignments, and provisioning. A user could be an owner of one and not the other. If you are auditing ownership, you need to check both.
During incident response, reviewing only app registration owners misses half the picture. A compromised service principal owner can manipulate SSO configuration and user assignments in ways that are just as damaging as credential abuse.
The Risk Is Not Limited to API Permissions
Most discussions about app registration risk focus on API permissions, and rightly so. Application permissions that operate without a signed-in user represent the most direct path to privilege abuse. But they are not the only risk.
An app registration that is configured as an OIDC or SAML identity provider for federated SSO into downstream applications introduces a different category of risk entirely. If an application in your tenant is the identity bridge for a critical platform like Splunk, Okta, ServiceNow, or your SIEM, then control over that app registration's redirect URIs and SSO configuration is control over authentication to those platforms.
An attacker who gains ownership of that app registration does not need Directory.ReadWrite.All. They can modify redirect URIs to intercept authentication tokens. They can alter claims mappings. They can tamper with the SSO profile to redirect users to infrastructure they control. The downstream application trusts the tokens your tenant issues. If the app registration issuing those tokens is compromised, that trust becomes a weapon.
This means the risk assessment for ownership cannot be based solely on what Graph API permissions are assigned. You also need to consider what the application authenticates to, because an app with zero API permissions but a SAML SSO profile pointed at your security tooling is a high-value target.
The Agentic AI Acceleration
This problem is about to get significantly worse.
Microsoft Entra Agent ID, announced at Ignite 2025 and now in expanded public preview, introduces agent identity blueprints as a new identity construct purpose-built for AI agents. These blueprints function as templates that create and manage agent identities, which are themselves modelled as service principals in your tenant. The blueprint holds credentials and can acquire tokens on behalf of agent identities.
This matters for ownership governance because the volume and velocity of application identities is about to scale in ways most organisations are not prepared for.
Platforms like Microsoft Copilot Studio, Azure AI Foundry, and Microsoft 365 Agent are already creating agent identities automatically. Each agent needs permissions. Each agent authenticates using credentials managed through its parent blueprint. The blueprints themselves are application objects that can have owners.
If your organisation is still applying a blanket "every app must have an owner" policy without differentiating by risk, you are about to apply that policy to a rapidly growing population of AI agent identities. The same ownership risks that exist for traditional app registrations, the ability to add secrets, the ability to create credentials that operate outside user-based controls, will apply to agent identity blueprints as well.
Organisations that have not matured beyond uniform ownership policies will find themselves assigning standard users as owners of agent blueprints that hold meaningful permissions, and doing so at scale.
A Maturity Model for Ownership Governance
What follows is a four-stage model for how organisations should evolve their approach to app registration ownership. Most organisations are at Stage 1 or Stage 2. Very few have reached Stage 4. The goal is not perfection but progression.
Stage 1: Unmanaged
There is no ownership policy. App registrations are created by whoever needs them. Many have no owner at all. Others have owners who left the organisation months or years ago. Secrets expire without anyone being notified because Entra ID does not send expiration alerts to owners by default.
This is where most small-to-mid organisations sit. Many large organisations are here too. They just do not know it.
The problem at this stage is not ownership. It is visibility. You cannot govern what you cannot see. The first step is not writing an ownership policy. It is understanding what you have.
Diagnostic — find out where you stand:
GET https://graph.microsoft.com/v1.0/applications?$count=true&$filter=owners/$count eq 0&$select=id,displayName
ConsistencyLevel: eventualThis returns every app registration with no owner. Run the same query for service principals:
GET https://graph.microsoft.com/v1.0/servicePrincipals?$count=true&$filter=owners/$count eq 0 or owners/$count eq 1&$select=id,displayName
ConsistencyLevel: eventualIn 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"If either of those numbers surprises you, you are at Stage 1.
Stage 2: Blanket Ownership
Governance says every app registration must have an owner. The organisation assigns owners across the board, typically the developer who built the application or the person who submitted the request. This feels like progress.
The problem is that ownership is being applied uniformly. The developer who owns a basic OIDC app with openid and profile delegated permissions is treated the same as the developer who owns an automation service with Directory.ReadWrite.All application permissions. The governance policy does not differentiate because it was written around accountability, not risk.
This is the stage where most organisations create risk while believing they are reducing it.
A standard user who owns a low-privilege app registration is fine. That same standard user owning a high-privilege app registration has, in effect, been granted 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, store it externally, and maintain persistent access as the application identity. During incident response, the compromised user account will be the focus. The app registration ownership is unlikely to be reviewed.
Diagnostic — identify 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 -AutoSizeThis 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.
Stage 3: Risk-Differentiated Ownership
The organisation begins classifying app registrations by their risk profile and applying ownership policies accordingly. This is where real maturity starts.
Low-risk applications have only delegated permissions with narrow scopes such as User.Read, openid, profile, and offline_access. The application can only act within the bounds of the signed-in user's own access. Ownership by a standard user is appropriate here. The blast radius is limited.
Medium-risk applications have broader delegated permissions such as Mail.ReadWrite or Files.ReadWrite.All, or a small number of low-sensitivity application permissions. Ownership is still practical, but it should be accompanied by monitoring. Set up audit log alerts on Add service principal credentials and Update application – Certificates and secrets management events. Review the owner list quarterly.
High-risk applications have high-impact application permissions such as Directory.ReadWrite.All, User.ReadWrite.All, AppRoleAssignment.ReadWrite.All, RoleManagement.ReadWrite.Directory, or Mail.Send as an application permission. Applications that serve as the SSO bridge for critical downstream platforms (your SIEM, your identity provider, your PAM solution) also fall into this tier regardless of their API permissions.
At this tier, ownership should either be removed entirely or restricted to hardened admin accounts that are subject to the same controls as any other privileged identity: PIM-eligible, phishing-resistant MFA, and dedicated admin devices. Standard user accounts should never own applications at this tier.
The key shift at Stage 3: the organisation recognises that ownership is not a uniform governance control. It is a privilege assignment that should scale with the risk profile of the application.
Stage 4: Separated Accountability
Ownership and accountability are formally decoupled. The organisation no longer uses Entra ownership as an accountability mechanism for high-risk applications.
Custom Security Attributes handle governance metadata. You define attributes for business owner, technical contact, cost centre, data classification, and lifecycle status. These attributes are assigned to the enterprise application (service principal) and are manageable through the Entra admin centre, Graph API, or PowerShell. They provide full audit traceability without granting any credential management capability.
Custom Security Attributes are business-specific key-value pairs that can be assigned to users, service principals, and other Entra objects. They require the Attribute Assignment Administrator role to assign and the Attribute Assignment Reader role to view. Critically, Global Administrator and other admin roles do not have access to custom security attributes by default, which means your governance metadata is isolated from your operational controls.
Ownership (the Entra capability) is only assigned where there is a genuine operational need for someone to manage credentials, and only to accounts with an appropriate privilege posture. For high-risk applications, this may mean no owner at all. Credential operations are handled by administrators through controlled processes, or automated through workload identity federation and managed identities where possible.
At this stage, ownership changes on high-privilege applications are treated as security signals, not routine governance events. The Add owner to application audit event gets the same scrutiny as a role assignment change.
Assessing Your Current Stage
Ask yourself these questions:
Do you know how many app registrations in your tenant have no owner? If not, you are at Stage 1.
Do you have an ownership policy, but it applies the same rules to every app registration regardless of permissions? You are at Stage 2. This is where most organisations stop. It is also where the most dangerous assumptions live.
Do you differentiate ownership requirements based on the application's permission profile and SSO relationships? You are at Stage 3.
Have you formally separated accountability metadata from credential management authority using Custom Security Attributes or equivalent tooling? You have reached Stage 4.
Practical Recommendations
Regardless of your current stage, these actions reduce risk immediately:
Monitor credential additions. Alert on the Add service principal credentials and Update application – Certificates and secrets management audit events. This is the single highest-value detection for ownership abuse.
Audit both object types. Ownership on the app registration and ownership on the service principal are independent. Review both during any access review or incident response.
Review SSO-configured applications. Identify every app registration in your tenant that serves as a SAML or OIDC identity provider for downstream applications. These are high-value targets regardless of their API permission profile.
Classify before you assign. Before assigning an owner to any app registration, check whether it has application permissions or SSO relationships with critical platforms. If it does, apply Stage 3 or Stage 4 controls.
Prepare for agentic scale. If your organisation is adopting Copilot Studio, Azure AI Foundry, or any platform that creates agent identities, extend your ownership governance to cover agent identity blueprints. These are application objects and are subject to the same risks.
Conclusion
Governance frameworks are drawn to simple rules. "Every app registration must have an owner" is a simple rule. It is easy to write, easy to audit, and easy to report on.
It is also the wrong rule for a growing number of your applications.
Ownership in Entra ID is not an accountability tag. It is credential management authority. When applied to applications with high-impact permissions or critical SSO relationships, it is a privileged capability. When applied uniformly to a standard user account across every app registration in the tenant, it creates unmonitored privilege paths at scale.
The maturity model is straightforward: start with visibility, move to risk-based differentiation, and evolve toward formal separation of accountability and credential authority. Most organisations will not reach Stage 4 overnight. That is fine. Moving from Stage 2 to Stage 3 is where the most meaningful risk reduction happens.
The number of application identities in your tenant is about to grow significantly. Between agentic AI, automation, and the continued migration of workloads into the Microsoft identity platform, the apps that need governance will outnumber the humans who manage them. Build an ownership model that scales with that reality now, not after the next incident.
If an application can act with tenant-wide authority, ownership of that application is part of your privilege model. Govern it accordingly.