Technical Bulletin: Onboarding Service Principals and Vendor Applications

The app onboarding process spectrum: simple or self-inflicted complexity

Onboarding an application, whether it's an internally registered service principal or a third-party multi-tenant (vendor) application you're consenting to in your tenant, sits on a spectrum. It can be as easy as a single owner registering an app and consenting to a narrow, delegated permission. Or it can become a multi-month gauntlet of committees, sign-offs, and re-reviews.

Neither extreme is healthy. Too little process and you accumulate over-privileged, unowned, unmanaged identities, exactly the apps holding tenant-wide Mail.* and similar rights that keep security teams up at night. Too much process and the business routes around you, shadow IT flourishes, and legitimate projects stall. The goal is a process that applies the right level of scrutiny to the right applications.

What should an application onboarding policy include? What are the review dimensions?

In larger organizations, application onboarding deserves consideration across several distinct lenses. Each answers a different question, and each can independently block or shape a request:

That last lens is often overlooked and frequently the most valuable: a surprising share of onboarding requests are for capabilities the organization already owns. Catching duplication early saves licensing spend, reduces your attack surface, and avoids onboarding work that never needed to happen.

You can't align with an application governance policy you don't have

Every one of those checkpoints exists to answer a single underlying question: Does this request align with policy? Which surfaces the obvious prerequisite...you must have a policy to align with.

If your organization doesn't have a defined application onboarding policy, that's the first deliverable, not the review board. Again, it doesn't have to be overcomplicated, but the policy should establish:

• What qualifies as an application subject to onboarding (app registrations, enterprise apps / consented multi-tenant apps, service principals with credentials).
• Who owns each application and is accountable for it over its life (both from the technical and business sponsorship perspectives)
• What permission levels trigger which reviews (delegated vs. application permissions; read vs. write; mailbox, directory, and other high-impact scopes).
• The decision criteria each lens uses, so reviews are consistent and defensible rather than ad hoc.
• The lifecycle expectations, including milestones like credential rotation, recertification, and offboarding.

Without this, every review becomes a fresh negotiation, which is precisely what makes onboarding slow and unpredictable, frustrating users and impeding productivity.

When does friction become a problem in the application onboarding process?

A real onboarding process introduces friction, and some friction is the point. It's the mechanism that forces a pause to confirm an application request is the right direction before it's wired into production identity infrastructure.

But friction has a failure mode. We have seen review processes stretch into weeks and months, during which the business waits, momentum dies, and stakeholders lose faith in the process. When the official path is too slow, people find unofficial ones, and shadow onboarding is far riskier than the process you were trying to enforce.

The discipline is to deliver the checks without being overly aggressive. The application onboarding process should be proportional to risk, not uniform across everything.

A process solution: risk-tiered application onboarding

The way to keep friction proportional is to triage every request before it enters the full review pipeline and route it to the appropriate level of scrutiny.

Tier 1 - Low risk (fast lane). Internally owned apps requesting narrow, delegated, read-only or sign-in scopes. A lightweight self-service registration with an owner of record and an automated policy check. Minutes to hours.

Tier 2 - Moderate risk (standard review). Apps requesting broader delegated scopes or vendor apps with limited application permissions. Security and architecture sign-off against the policy, with a published SLA. Days.

Tier 3 - High risk (full board). Any app requesting application-level permissions to high-impact data - Mail.*, Directory.*, broad write or send scopes, EWS full access, and most multi-tenant vendor apps touching sensitive data. The full set of lenses applies: architecture, engineering, security, legal, and product. This is where deliberate friction is justified.

Two practices keep even Tier 3 from becoming a black hole:

• • Publish SLAs per tier and track them. A review with no deadline is a review that never ends.

  • Make the gate up front. Triage cost is low; expensive reviews run only on requests that genuinely warrant them.
    
    

Vendor (multi-tenant) applications deserve extra attention

Consenting to a third-party's multi-tenant app grants an external vendor a standing identity within your tenant, introducing a supply chain relationship, not just a software installation. For these, explicitly confirm: who owns the relationship internally, what permissions are actually required versus requested, whether conditional access and credential controls apply, and what happens to the consent and service principal when the contract ends.

Don't forget the back half: application ownership and offboarding

Onboarding is only the beginning of the lifecycle. An app admitted without understanding both the technical owner and business sponsor, a credential expiry plan, and a recertification cadence becomes an orphaned, over-privileged identity the moment the original sponsor moves on. Bake offboarding and periodic recertification into the onboarding policy. It's far cheaper than discovering the gap during an incident or an audit.

Application onboarding process recommendations

1. Write the policy first. You cannot run consistent reviews against criteria that don't exist.

2. Triage before you review. A risk-tiering gate at intake is the single biggest lever for keeping friction proportional.

3. Reserve the heavier review for high-impact permissions: application-level Mail.*, directory, and broad write/send scopes, plus most vendor apps (permission dependent).

4. Put SLAs in place for every tier and measure them. Weeks-to-months reviews are a process failure, not a badge of thoroughness.

5. Treat vendor apps as supply-chain relationships, with named internal ownership and a defined end-of-contract teardown.

6. Close the loop with lifecycle controls: ownership, credential rotation, and recertification defined at onboarding.
   
   

Before you refine your application onboarding process, measure your governance baseline

Every new application request adds to an existing Entra ID application landscape. If you lack visibility into current application permissions, credential hygiene, ownership, or governance controls, it can be difficult to make informed onboarding decisions and enforce risk-based policies consistently.

ENow AppGov Score helps organizations evaluate their current application governance maturity by providing visibility into application inventory, ownership, permissions, and governance controls across Microsoft Entra ID.

See how your tenant scores and identify opportunities to strengthen application governance before your next onboarding request arrives. Get Your AppGov Score