App Developer vs Cloud App Administrator: Getting Entra ID Governance Right

I want to engage with a common concern seriously — not to dismiss it, but because I think the framing leads us toward the wrong solution, and away from a governance gap that deserves more attention.

I'll be transparent: I'm apparently part of the motivation for a recent discussion on this topic. My developer identity was assigned as an owner to an app registration, and that was flagged as a risk. I'd like to explain why, in context, it isn't one — and why the actual risk in that environment may be something that discussion never addressed.

Where the Concern Gets It Right

Let's start with agreement, because there's real substance here.

Application identities in Entra ID operate outside the control plane that governs human accounts. There is no Privileged Identity Management (PIM) activation. There is no MFA prompt. Once a client secret or certificate exists on an application, it can authenticate repeatedly without challenge until it expires or is revoked.

Note: Incident response teams often focus on compromised user accounts without thinking to audit whether that user owned a high-privilege application. That's a blind spot worth closing.

And yes — apps holding permissions like Directory.ReadWrite.All or AppRoleAssignment.ReadWrite.All warrant elevated scrutiny. Those are powerful credentials.

None of that is in dispute. The question is whether ownership itself is the source of risk, or whether the risk lives somewhere else.

Where the Framing Falls Short

The common framing conflates two meaningfully different scenarios:

1. A malicious actor gaining ownership of a privileged application as an attack vector
2. A developer being assigned as the owner of an application they built and are responsible for

These are not the same situation. One is a threat. The other is normal software development.

The proposed alternative — using Custom Security Attributes to document a business owner and technical owner — is a documentation solution to an operational problem. It tells you who is accountable. It gives no one the ability to rotate a secret, update a redirect URI, or respond to a certificate expiration. Any developer working on a real application needs those capabilities. Stripping ownership and replacing it with metadata creates a governance checkbox and a support bottleneck.

Warning: Custom Security Attributes answer "who is accountable?" Ownership answers "who can act?" Both have a place. They are not substitutes for each other.

The Question That Goes Unasked

Here's what I think is the more important governance question:

If developers don't have ownership of their applications, how are they getting the access they need to do their work?

In many environments, the answer is: they're being given Cloud App Administrator.

That's a much bigger problem than ownership.

Cloud App Administrator is a directory-wide role. It grants the ability to manage all application registrations and enterprise applications in the tenant — not just the ones a given developer built. In some configurations it can also influence consent grants.

If a developer account is compromised and that developer holds Cloud App Administrator, an attacker has broad reach across every application in your directory. If that same developer owns only their own apps with a properly scoped role, the blast radius is limited to the applications they were already responsible for.

Tip: The risk isn't that a developer owns an app. The risk is granting tenant-wide administrative capability because you haven't properly scoped developer access.

The Role Microsoft Built for This: App Developer

Microsoft ships a built-in RBAC role called App Developer. It is specifically designed to give developers what they need without elevating them into administrative territory.

Under this role, a user can:

• Register new applications
• Manage applications they own
• Create service principals

All without any visibility or control over applications registered by others.

Pair App Developer with object-level ownership of the specific application a developer is responsible for, and you have a clean, defensible access model:

• The developer can manage their own app's credentials, redirect URIs, and configuration
• They cannot touch any other application in the tenant
• If their account is compromised, the blast radius is scoped to their own app
• Audit logs for credential additions still fire — you keep full visibility

This is not a workaround. It's the model Microsoft designed. The problem is that many environments skip it, reach for Cloud App Administrator because it's faster to assign, and then treat the resulting broad access as a reason to distrust ownership entirely.

Where Ownership Deserves Tighter Controls

To be fair: not all app registrations are equal, and ownership on high-privilege apps does warrant more careful governance.

An application holding AppRoleAssignment.ReadWrite.All or RoleManagement.ReadWrite.Directory is effectively a privileged identity. A standard developer account probably shouldn't own that application — not because ownership is inherently dangerous, but because the combination of a high-exposure account and a high-privilege application creates unnecessary risk.

The right answer there isn't to eliminate ownership broadly. It's to tier your governance model based on what the application can actually do.

| App Type | Appropriate Owner | Developer Role | |----------|-------------------|----------------| | Low/medium privilege (OIDC, delegated, scoped application permissions) | Developer who built it | App Developer | | High privilege (tenant-wide application permissions) | Dedicated service account or restricted admin identity | Restricted — PIM if needed | | Critical/infrastructure (RoleManagement, AppRoleAssignment) | No owner, or Global Admin only | No developer ownership |

Practical Recommendations

Rather than eliminating ownership, consider this approach:

1. Use the App Developer role for developers — not Cloud App Administrator
2. Assign ownership based on the privilege tier of the application, not as a blanket policy
3. Monitor audit logs for Add credentials to application events regardless of who the owner is
4. Periodically audit application permissions inventory — especially for high-privilege application permissions that have been admin consented
5. Use Custom Security Attributes for accountability metadata, not as a replacement for operational ownership
6. Reserve stricter controls (no owner, admin-only access) for apps with tenant-wide authority

Closing Thoughts

The spirit of the original concern is right: application identities deserve serious governance, and too many organizations treat them as an afterthought compared to privileged user accounts.

But the solution isn't to treat ownership itself as a threat. It's to ensure that the access model around app registrations is built correctly in the first place — with properly scoped roles, tiered ownership policies, and monitoring that covers credential additions across all applications.

If a developer owning their own app registration is the riskiest thing in your Entra environment, you're in good shape. If developers are getting Cloud App Administrator because you haven't set up App Developer roles, that's where the energy should go.

Note: Ownership isn't the silent path to persistence. Broad administrative roles handed out for convenience — that's the quiet risk multiplier worth writing about.