An Entra application registration is the template for an application, while its service principal defines what that application can actually do in a particular tenant, according to Microsoft's application-object guidance. That distinction matters to a buyer: reviewing a registration alone does not establish the access granted in production. A useful penetration test follows the authorized application through its local identity, consent grants and protected resources, then shows which control allows or blocks a consequential action.
Quick answer. Scope an Entra app registration penetration test around the application object, each in-scope tenant service principal, effective delegated and application permissions, consent policy, owners, credentials and redirect URIs. Use test identities and data to demonstrate an access path without touching another tenant or unauthorized data. Stingrai's human-led Azure and Entra ID testing explicitly covers app registrations, service principals and consent grants.
This guide is for a security leader, identity owner or procurement team buying a bounded application-identity test. It gives you an inventory request, a statement-of-work boundary, the evidence to require and questions that reveal whether a vendor will assess effective privilege rather than merely export settings. The broader tenant, Conditional Access and Azure subscription scope belongs in our Azure and Entra ID penetration testing guide; this guide goes deep on the registration-to-consent path.
What is the test actually trying to prove?
The central question is whether an application can obtain more access than its business purpose requires, or whether someone with control over the registration can enlarge that access. Microsoft calls an application overprivileged if it holds an unused or reducible permission and recommends removing unused access or replacing it with a narrower grant (Microsoft, least privilege guidance). A test should turn that principle into observable evidence: the permission granted, the principal that holds it, the resource reachable with it and the control that should have constrained it.
Treat this as an identity and application boundary assessment. It is narrower than a complete cloud penetration test, which may also cover subscriptions, managed identities, storage, compute and Conditional Access. It is also narrower than a general SaaS connected-app program, which maps OAuth grants across many vendors. The Entra-specific object model, Microsoft Graph permissions and consent workflow are the subject here. If your estate also includes Salesforce or other SaaS grants, our SaaS OAuth connected-app scope guide describes that adjacent work.
Registration and service principal are different evidence sources
Microsoft says the application object lives in its home tenant and acts as the template for service principals. The service principal is the local representation in each tenant where the app is used. Its permissions and access policy are what matter in that tenant (Microsoft, application and service principal objects). The buyer should therefore ask for both configuration and effective grants. A home-tenant registration export without a tenant service-principal view can miss the access that actually exists. Conversely, a tenant grant view without the registration's owner, credentials and redirect settings can miss who can change the application.
Figure 1: Where to collect configuration, grant and access evidence in one tenant. Sources: Microsoft, application and service principal objects and Microsoft, application-property security.
Inventory to put in the statement of work
Hand the tester an approved list of registrations and enterprise applications, with an internal owner for each. Microsoft directs administrators to the App registrations page for application objects and Enterprise applications for service principals and their permissions (Microsoft, application and service principal objects). The business owner should add the intended function, data classification and environment. That lets the tester compare actual access with a stated need rather than treating any broad permission as automatically wrong.
Inventory field | What the buyer supplies | What the tester verifies |
|---|---|---|
Application and tenant identity | Registration ID, home tenant, in-scope service principal, business owner | The objects and grants being assessed are the approved ones |
Intended function | APIs called, supported users, expected records and operations | Effective access matches that function |
Permissions and consent | Configured API permissions, granted delegated scopes, app-only roles, consent records | The grant is necessary, appropriately approved and no broader than the workflow |
Registration control | Owners, credential types and expiry, redirect URIs, app instance settings | A lower-trust maintainer or stale endpoint cannot change the access path |
Test fixtures | Synthetic users, roles, test data, sandbox app and response contacts | Evidence can be collected without exposing real customer records |
The table is a purchasing tool, not a request for production secrets. A vendor can inspect credential metadata and handling without receiving usable secret values. The agreement should spell out whether source code, configuration exports and sign-in or consent logs will be available, because those change how directly the tester can prove a path.
The checks that make the engagement specific
Compare configured permissions with effective grants
The registration may declare permissions, but the tenant's service principal and consent records show granted access. Microsoft documents separate views for administrator consent and user consent in Enterprise applications (Microsoft, review permissions granted to applications). Ask the tester to reconcile those views with the application owner and the API calls the app actually makes. The finding should say whether a permission is unused, reducible or genuinely required, and what would break if it changed. Microsoft's least-privilege guidance makes those categories explicit (Microsoft, least privilege).
Separate delegated permissions from application permissions in the evidence. Microsoft explains that application permissions permit access without user interaction, while delegated permissions let an app act for a signed-in user (Microsoft, consent management). The test therefore needs distinct expected-access cases. A role matrix should show what the app may reach with a synthetic user context and what it may reach without one. Where Microsoft Graph offers a less permissive grant that still supports the app's task, the recommendation should identify that alternative rather than merely say "reduce permissions."
Test the consent decision, not just the prompt
Consent is the point where requested permissions become authorized access. Microsoft recommends restricting user consent to selected permissions and verified publishers, with other decisions handled by security and identity administrators (Microsoft, consent management). A scoped test can validate who is able to request access, who can approve it, whether the approval applies to one user or the organization, and whether the resulting grant matches the decision recorded by the business owner.
Tenant-wide admin consent deserves a specific approval trace. Microsoft describes it as a sensitive operation and advises administrators to evaluate the publisher, requested permissions and expected application features before granting it (Microsoft, consent management). The tester should observe the workflow with a harmless test app and test accounts, then document the decision path. Do not ask a tester to obtain a broad production grant simply to prove one could be requested. A safe demonstration shows the reachable decision point and the proposed control change, with the identity owner approving any live change.
Review who can change the registration
Microsoft states that owners can manage all aspects of a registered application and recommends keeping ownership to a minimal set (Microsoft, application-property security). The test should identify direct owners, the teams behind them and how access is removed when a person changes roles. Ownership matters because it changes the security of credentials, redirect URIs and requested access. Ask for an evidence chain that connects an in-scope principal to a concrete configuration capability. A flat list of owners tells you less than a demonstrated change path with an approved test registration.
Credentials need an equally practical review. Microsoft's guidance favors managed identity where suitable, then certificate credentials when that is not possible; it warns against password credentials and asks owners to review use and expiry (Microsoft, application-property security). The test should inspect credential types, storage and rotation ownership, but should use safe metadata and test credentials. The report should identify which application would be affected by a compromised credential and how to revoke it, without placing a live secret in evidence.
Treat redirect URIs and audience settings as trust boundaries
Microsoft warns that lost ownership of a redirect URI can lead to application compromise and recommends a small, current URI list with no wildcard reply URLs or insecure schemes (Microsoft, application-property security). Ask the tester to check URI ownership against current DNS and deployed environments, including retired staging domains. For an application exposing its own API, include its identifier URI and token audience validation. Microsoft describes the application ID URI as part of the token audience and instructs resource apps moving to a newer token format to validate the intended audience (Microsoft, application-property security).
These checks belong in the same story as permissions. A safe test should show whether a configuration change could reroute authorization material or cause an API to accept a token meant for another resource. It should document expected behavior and the observed result with test tokens. It should not attempt to capture real-user authorization responses.
Rules of engagement and safe proof
Microsoft's security testing rules apply to the owner and its authorized consultants. They prohibit accessing data or systems without permission, using someone else's secrets, denial-of-service testing and testing another tenant without authorization. The statement of work should name the tenant, registrations, service principals, test accounts, protected resources, dates, contacts and stop conditions. If a multitenant app is involved, do not assume that an organization's ownership of its home registration permits testing a customer's tenant.
The useful proof is a bounded path, such as a test principal reaching a synthetic record outside the intended role, or an owner being able to alter a harmless test registration contrary to policy. Capture only what is needed to establish the finding. If a path would touch production data or make a disruptive configuration change, stop at the last safe step and state the unproved impact as a hypothesis. That distinction helps security and audit readers understand exactly what was demonstrated.
Deliverables a buyer should ask for
The report should give the identity owner a prioritized set of remediations and give procurement evidence that the quoted scope was actually completed. Require an object inventory, a permission-and-consent comparison, an attack-path narrative for each material issue, the exact test fixture used, a business-impact explanation, an owner, and a retest result. Include an appendix that maps each tested registration and tenant service principal to the relevant finding or to a clear "no issue observed within scope" statement. That guards against a broad claim of coverage when only a few apps were sampled.
An executive summary should distinguish three outcomes: what was directly proven, what was inferred from configuration, and what was outside authorization. For an overprivileged permission, ask for the narrower candidate and a rollout note. For a redirect URI, ask for the owner and deployment that must change. For a consent weakness, ask for the policy or approval step that would have blocked it. These are decisions an identity team can act on, not merely severity labels.
Questions to ask a penetration testing vendor
Will you inspect the application object and the service principal's effective tenant permissions separately?
How will you compare required API calls with unused or reducible Microsoft Graph permissions?
Which test identities and synthetic resources do you need to prove delegated versus app-only access safely?
How will you assess who may grant user and tenant-wide consent without requesting a broad production grant?
Will your report connect registration owners, credentials and redirect URIs to specific access paths?
What is your stop rule if a path reaches data or a tenant outside the signed authorization?
What evidence and retest result will each finding include, and how will secrets be kept out of the report?
Ask for a sample redacted finding. A strong sample identifies the affected app and service principal, the grant or setting, the authorized proof, the business effect, the smallest viable fix and the retest outcome. A screenshot of the permission list alone does not answer the buyer's question.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing service provider whose Azure and Entra ID scope includes application registrations, service principals and consent grants. This is human-led cloud identity work. Stingrai's testers can scope a one-time engagement or a continuous program around your approved apps, tenant and test data, with findings delivered as they are confirmed and retesting of remediated findings included, as described in the service and delivery model. The report supports access-governance and compliance programs with tested evidence; it is not a substitute for the organization's own approval decisions.
For applications where the same trust path reaches a web application and associated APIs, a combined scope can also include web application penetration testing. The identity owner and application owner should agree in advance where the Entra test ends and the application authorization test begins, so neither team assumes the other has covered the gap. Engagements involving multiple registrations, tenants or cloud resources are scoped through Get a Quote.
Frequently Asked Questions
What should an Entra app registration penetration test cover?
It should cover the application object, its in-scope tenant service principal, effective delegated and application permissions, consent decisions, owners, credentials, redirect URIs and a safely demonstrated access path. The report should compare actual access with the application's stated business purpose and identify a specific fix for each material gap.
Is an app registration the same as a service principal?
No. Microsoft describes the application object as the template in its home tenant and the service principal as the local application identity in a tenant where the app is used. A buyer needs evidence from both to understand configuration and effective access.
Does a consent review require granting new production permissions?
No. A consent workflow can be exercised with approved test identities and a harmless test application. The tester can document who could approve a sensitive request, what grant would result and where the control should stop it, while leaving production grants to the identity owner.
Can a third-party tester assess every customer tenant of a multitenant app?
Only the tenants and resources explicitly authorized by their owners. Microsoft's security testing rules prohibit touching data or systems without permission. A home-tenant registration does not confer authorization over another organization's service principal or data.
What evidence should the report give my identity team?
It should identify the affected registration and service principal, permission or configuration, approved proof, expected versus observed access, business effect, precise remediation owner and retest result. It should separate demonstrated impact from a plausible but untested path.
Related reading
References
Microsoft Learn. Application and service principal objects in Microsoft Entra ID. Read the documentation. Defines the object and tenant-instance model.
Microsoft Learn. Security best practices for application properties in Microsoft Entra ID. Updated October 1, 2026. Read the documentation. Covers registration owners, credentials, redirect URIs and permissions.
Microsoft Learn. Enhance security with the principle of least privilege. Updated October 23, 2023. Read the documentation. Defines unused and reducible permissions.
Microsoft Learn. Application consent management and evaluation of consent requests. Read the documentation. Explains user and administrator consent decisions.
Microsoft Learn. Review permissions granted to enterprise applications. Read the documentation. Describes the tenant grant views.
Microsoft Security Response Center. Microsoft Security Testing Rules of Engagement. Read the rules. Defines authorized testing boundaries.
Talk to Stingrai
Send your registration inventory and intended business workflows through Get a Quote, or book a free discovery call to define a safe Entra app-identity test scope.
