A practical engineering guide to owners, assignment, consent, credentials and risk

Contents

• Why this topic trips people up
• The core objects: App Registration, Enterprise Application and Service Principal
• Consent and permissions: where the blast radius lives
• Delegated permissions vs application permissions
• Assignment required: useful, but often misunderstood
• Owners: accountability, administration and privilege
• Credentials, certificates and secrets
• App instance property lock
• A practical review framework
• Engineering checklist and references

Why this topic trips people up

Microsoft Entra application governance looks simple until you start reviewing real tenants.  Then the terminology gets slippery.  App Registrations, Enterprise Applications, service principals, owners, assignments, consent, permissions, app roles, user roles, secrets and certificates all appear in related admin screens, but they do not mean the same thing and they do not control the same risk.

That confusion matters.  It is common to see teams treat an ownerless app as an access problem, or treat assignment required as if it reduces Microsoft Graph permissions.  It is also common to see business users added as owners of privileged app registrations because “every app needs an owner”.

The intention is good, but the control is wrong.

This article is written as a practical crib sheet for Microsoft 365 and Entra engineers.  It deliberately focuses on review and governance decisions rather than product marketing terminology.

The core objects

The cleanest way to start is to separate the three objects that engineers most often blur together: the application object, the service principal, and the Enterprise Application experience in the portal.

Microsoft describes the relationship as application objects and service principal objects.  A single application object can have service principal instances in tenants where the application is used.  For engineers, the simplest mental model is this: App Registration equals the definition; Enterprise Application/service principal equals the local instance and identity in a tenant.

A simple relationship diagram

Consent and permissions: where the blast radius lives

Consent is where the real blast radius often lives.  If an application has powerful Microsoft Graph application permissions, the risk is not just that someone can click a tile in My Apps.  The risk may be that the application identity can read or modify large parts of the tenant without a user being present.

Permission review should answer practical questions:

• Who approved this permission?
• Why does the app need it?
• Is the permission delegated or application?
• Is admin consent granted?
• Is the permission still required?
• What data, directory objects, mailboxes, SharePoint sites or control-plane operations can the app access?

Delegated permissions vs Application permissions

This distinction deserves its own section because it is one of the most important concepts in application risk review.

Delegated permissions are not automatically safe

A delegated permission granted tenant-wide can still be risky if many users can sign in and the application can operate on behalf of those users.  But the user context still matters: the user must normally have access to the target resource or action as well.

Application permissions

Application permissions are often the bigger governance concern because the application runs as its own identity.  For background services, migration tools, automation jobs and reporting agents this is often necessary.  It is also why ownership, credential hygiene and permission review are so important.

Assignment required: useful, but often misunderstood

Assignment required is an Enterprise Application setting.  It controls whether users, groups, apps or services must be explicitly assigned before tokens are issued to that Enterprise Application.  It is an access control setting.

It does not control who owns the application.  It does not rotate credentials.  It does not remove consent.  It does not reduce Microsoft Graph permissions.  It does not turn a high-risk application into a low-risk application.

A good engineering question is therefore not simply “is assignment required enabled?” It is “does this app need open access, and if it does not, are the assignments deliberate, reviewed and appropriate?”

Owners: accountability, administration and privilege

Ownerless applications are a real governance problem, but the remediation is not always to add any available business user as an owner.  Adding an owner can grant meaningful administrative control.  For App Registrations, ownership can allow management of sensitive application configuration.

For Enterprise Applications, owners may be able to manage app-specific configuration such as SSO, provisioning and user assignment.

For low-risk SaaS Enterprise Applications, a business owner may be appropriate.  For app registrations with Graph application permissions, secrets, certificates or automation access, ownership should be treated as privileged.  A business owner can be recorded in an assessment tool or CMDB without necessarily being granted direct Entra owner permissions over a high-risk application object.

Credentials, certificates and secrets

Credentials are impersonation risk.  If an app has a client secret or certificate, anyone who obtains that credential may be able to authenticate as the application.  The risk is particularly high when the same application also has broad application permissions and admin consent.

The especially dangerous combination is:

App instance property lock

App instance property lock is related to the servicePrincipalLockConfiguration property.  In simple terms, it is designed to stop sensitive service principal instance properties being changed, especially for multi-tenant applications where the publisher wants to protect properties on service principal instances created in consuming tenants.

This is a useful control, but it solves a specific problem.  If an app registration in your own tenant has no owner, app instance property lock does not create accountability.  You still need someone or some controlled team responsible for why the app exists, who approved the permissions, who rotates credentials and who approves retirement.

A practical review framework

When reviewing Entra applications, avoid starting with a giant export and trying to read every property.  Start with risk patterns and then drill into the objects that matter.

A quick risk tiering model

Engineering checklist

The one-slide version

References

• Microsoft Learn: Application and service principal objects in Microsoft Entra ID
• Microsoft Learn: Permissions and consent in the Microsoft identity platform
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: Grant tenant-wide admin consent to an application
• Microsoft Learn: Assign users and groups to an application
• Microsoft Graph: Permissions overview

Microsoft Graph permissions reference