What is the difference between an app registration and a service principal in Microsoft Entra ID?

How the two objects differ in Entra ID

An app registration is the application’s global definition in microsoft entra id: its name, redirect URIs, exposed API permissions, secrets or certificates, and other configuration. A service principal is the tenant-specific representation that Entra uses to enforce access, consent, assignments, and sign-in behavior. The same app registration can have many service principals across tenants, but each tenant has its own local object and governance surface.

That distinction matters because the registration is about what the application is, while the service principal is about how that application is allowed to operate in a particular directory. In practice, defenders often see abuse on the service principal side first, because permissions, consent, and credentials frequently attach there rather than to the abstract registration object.

For multi-tenant apps, the registration is the shared template and the service principal is the tenant’s instantiated copy. If you only inspect the registration, you can miss tenant-local permissions, delegated consent, admin consent grants, and app role assignments that determine real access. That is why the Entra ID Applications and Consent Guide is useful for understanding where consent and Graph permissions actually land in the tenant.

Why defenders should watch the service principal first

The service principal is usually the object that becomes operationally dangerous because it is what gets assigned roles, granted consent, or given runtime permissions in the tenant. A benign-looking registration can still become a high-risk tenant foothold if its service principal is overprivileged, linked to a long-lived secret, or trusted by admin consent. Real-world abuse often follows that path, as shown in the Storm-1283 OAuth apps abuse 2023 case, where attackers used app secrets to operate in Entra ID and expand impact.

The same pattern appears when an enterprise app is left active after the business owner has forgotten about it, or when a third-party app receives broad Microsoft Graph permissions that were approved once and never reviewed again. The registration may still look normal, but the service principal can retain standing access in the tenant long after the original business need has changed. The Azure RBAC and Service Principals Guide is relevant here because role assignment and scope are often what turn an app object into a real privilege path.

Service principals also become important during credential theft, certificate abuse, and tenant-to-tenant attacks. If a secret or certificate is attached to the service principal, compromise of that material can let an attacker authenticate as the app without touching an interactive user account. The Cloud Workload Identity Guide helps frame why app credentials, managed identities, and workload authentication need the same governance discipline as human access.

What to check when you inventory both objects

Start by mapping each app registration to its tenant-local service principals, then compare what the registration says against what each principal can actually do. Look for tenants where the service principal has been granted permissions, consented scopes, directory roles, or app role assignments that are not obvious from the registration record alone. Also check whether the object has owners, whether those owners are still current, and whether credentials or certificates are still valid but no longer justified.

Cross-check whether the application is a first-party, multi-tenant, or third-party app, because the review path differs. A single app registration can support many principals, but governance decisions, alerting, and incident response usually need to happen per tenant instance. The Active Directory and Entra ID Hardening Guide is useful for the broader governance context around privileged access, delegation, and hybrid identity.

If the question is whether the registration or the principal should be remediated first, the usual answer is the principal, because that is the object tied to live permissions and tenant-specific exposure. But if the underlying app definition is compromised, malformed, or cloned across tenants, the registration itself can become the root problem. The safest approach is to treat the registration as the design record and the service principal as the enforceable access object.

Risk and Threat Considerations

Misunderstanding the split creates a real exposure gap: teams may believe an app has been reviewed because its registration looks acceptable, while the service principal still has active permissions, consent, or secrets in a tenant. That gap is attractive to attackers because it lets them persist through an apparently legitimate enterprise application rather than a noisy interactive account.

Failure mechanism: A tenant-local service principal retains overbroad consent, stale credentials, or role assignments after the business need has changed, enabling abuse of the app’s trusted identity.

Impact: Attackers can use the principal to access Graph data, move through SaaS integrations, or operate under delegated trust without immediately triggering user-account alerts.

Practitioner Guidance

What to verify: Confirm that every app registration with tenant access has a corresponding inventory of service principals, owners, granted permissions, and credential material. If you cannot explain why a service principal exists in a tenant, treat it as a governance problem, not just an inventory issue.

Decision rule: If the service principal has active permissions or credentials, prioritize review of the principal’s consent, role assignments, and credential lifecycle before assuming the app registration itself is the main risk. If multiple tenants use the same app registration, review each tenant instance separately.

Practitioner takeaway: The registration defines the app, but the service principal is where real access lives, so Entra ID governance should focus on the tenant instance that can actually be abused.

Related resources from NHI Mgmt Group

• What is the difference between Microsoft Identity Manager and Entra ID Governance for hybrid identity management?
• What is the difference between Microsoft Entra ID audit logs and sign-in logs for security monitoring?
• What is the difference between using on-premises Active Directory as the identity authority and using Microsoft Entra ID as the primary identity system?
• What is the difference between agent identities, service principals and applications in Microsoft Entra?