Applications and Workload Identities

Not every identity in Microsoft Entra ID represents a person.

Applications, services, scripts, and automated processes may also need to authenticate and access protected resources. These non-human identities are commonly referred to as workload identities.

Understanding how applications are represented in Microsoft Entra ID is an important part of identity administration.

In this lesson, you’ll learn the foundational concepts behind application registrations, service principals, managed identities, and application permissions.

What You’ll Learn

By the end of this lesson, you should be able to:

Explain what a workload identity is
Understand the purpose of an application registration
Recognize the role of a service principal
Understand managed identities at a foundational level
Distinguish delegated permissions from application permissions
Recognize why application credentials must be protected
Apply least privilege to application access

What Is a Workload Identity?

A workload identity is an identity used by a software workload rather than a human user.

Examples can include:

Applications
Services
Automated processes
Scripts
Cloud workloads

Consider an application that automatically retrieves information from another service every night.

There may be no employee sitting at a computer entering a username and password.

The application itself needs an identity and an appropriate method of authentication.

This allows organizations to control what the workload can access instead of treating automated software as anonymous or giving it unnecessary user credentials.

Application Registrations

When developers integrate an application with the Microsoft identity platform, the application can be registered in Microsoft Entra ID.

An application registration establishes an identity definition for the application.

The registration can contain configuration related to areas such as:

Application identification
Authentication
Redirect locations
Credentials
API permissions
Other application settings

Think of the application registration as defining the application from an identity perspective.

Application Objects and Service Principals

Two concepts that can initially seem similar are the application object and the service principal.

A useful introductory distinction is:

Application object → the definition or blueprint of an application.

Service principal → the application’s identity within a particular tenant.

Suppose a software application is designed to work with Microsoft Entra ID.

The application object describes the application.

When that application needs to operate within a tenant, a service principal represents its local identity in that tenant.

This distinction becomes especially useful when working with applications that can be used by more than one organization.

Enterprise Applications

When administrators work with applications in Microsoft Entra, they’ll also encounter Enterprise applications.

This area is closely associated with service principals in the tenant.

From an administrator’s perspective, enterprise application management can involve areas such as:

User or group assignment
Single Sign-On
Permissions
Provisioning
Access controls

A useful foundational distinction is:

App registrations are closely associated with defining and configuring application identities.

Enterprise applications are closely associated with managing application instances and access within the tenant.

Delegated Permissions

Applications sometimes access resources on behalf of a signed-in user.

This is associated with delegated permissions.

For example, imagine an application that allows a signed-in employee to work with information that the employee is permitted to access.

Conceptually:

User signs in → Application acts on behalf of the user

The application’s effective access depends on the relevant permission and authorization context.

Application Permissions

Some applications need to operate without a signed-in user.

For example, an automated background service might run overnight and perform a scheduled task.

This type of scenario may use application permissions where appropriate.

Conceptually:

Application operates as itself → No signed-in user required

Because an application may operate independently, application permissions can be highly significant and should be carefully controlled.

Remember the fundamental distinction:

Delegated permissions → application acts on behalf of a signed-in user.

Application permissions → application acts as itself.

Consent

Applications requesting permissions can introduce another important concept: consent.

Depending on the permission, configuration, and organizational policies, consent may be provided by a user or may require an administrator.

Organizations should carefully manage application consent because granting unnecessary permissions can increase security risk.

A familiar principle applies:

Applications should receive only the permissions they actually require.

Least privilege applies to workloads just as it applies to human identities.

Application Credentials

An application may need credentials to authenticate.

Depending on the scenario, credentials can include mechanisms such as secrets or certificates.

Credentials must be protected carefully.

If an attacker obtains a valid application credential, the attacker may be able to impersonate the application and attempt to use its permissions.

This creates an important operational concern:

Application credentials are security-sensitive assets.

Organizations should avoid unnecessarily exposing or embedding credentials where they can be easily retrieved.

Managed Identities

For supported Azure resources, managed identities can help reduce the need for developers and administrators to manage credentials directly.

Azure manages the identity and its credentials, while administrators can grant the identity appropriate access to resources.

Conceptually:

Azure resource → Managed identity → Authorized resource

This can be preferable to placing a reusable secret directly inside application code or configuration.

System-Assigned Managed Identity

A system-assigned managed identity is associated with a particular Azure resource.

Its lifecycle is tied to that resource.

When the supported resource is created and the identity is enabled, the identity belongs to that resource.

When the resource is deleted, the associated system-assigned managed identity is also removed.

Think:

One resource → identity lifecycle tied to that resource

User-Assigned Managed Identity

A user-assigned managed identity is created as a separate Azure resource.

It can be assigned to supported Azure resources and has a lifecycle independent of any single resource using it.

Think:

Separate identity → can be associated with supported resources

The key distinction is lifecycle and management.

System-assigned → tied to a particular resource.

User-assigned → independently created and managed.

Practical Scenario

Suppose Contoso develops an automated application that processes business data every night.

The process runs without a user being signed in.

Using an employee’s username and password for the automation would create unnecessary security and operational problems.

Instead, the organization should consider an appropriate workload identity.

Administrators should then ask:

What resource does the workload need?
What permissions are actually required?
Does it need to operate without a user?
How will it authenticate?
Can credential management be reduced?
How can least privilege be maintained?

These questions help determine the appropriate identity and permission design.

Delegated or Application Permission?

Suppose another Contoso application displays a signed-in employee’s information.

The application is performing an action in the context of that user.

This points toward the concept of delegated permissions.

Now consider a background process that runs automatically at 2:00 a.m. when no user is signed in.

That points toward an application identity and application permissions where appropriate.

When analyzing a scenario, look for this clue:

Is there a signed-in user?

That can help distinguish between the two permission models.

SC-300 Exam Focus

Several terms in application identity scenarios are easy to confuse.

Remember:

Application registration
Defines an application’s identity configuration.

Service principal
Represents an application’s identity in a tenant.

Delegated permission
The application acts on behalf of a signed-in user.

Application permission
The application operates as itself without requiring a signed-in user.

Managed identity
Provides an identity for supported Azure resources while reducing direct credential-management requirements.

System-assigned managed identity
Lifecycle is tied to its Azure resource.

User-assigned managed identity
Exists independently and can be associated with supported resources.

Rather than memorizing the terms alone, understand what problem each concept solves.

Least Privilege for Applications

Least privilege applies equally to applications.

If an application only needs permission to read a particular type of information, it should not automatically receive broad modification privileges.

Excessive application permissions can create significant security exposure, particularly for unattended workloads.

When reviewing application access, ask:

What is the minimum access this workload requires to perform its function?

That is the same principle you’ve already applied to users and administrators.

Quick Review

Before continuing, make sure you understand:

Workload identities represent applications, services, and other non-human workloads.
Application registrations define application identity configuration.
Service principals represent applications within tenants.
Enterprise applications are closely associated with managing those application instances within a tenant.
Delegated permissions involve a signed-in user.
Application permissions allow an application to operate as itself.
Application consent and permissions should be carefully controlled.
Application credentials require protection.
Managed identities can reduce direct credential-management requirements for supported Azure resources.
System-assigned and user-assigned managed identities have different lifecycles.
Least privilege applies to workloads as well as people.

Continue to Lesson 7

You now understand how identities and access apply to both people and applications.

Next, we’ll look at identity governance and privileged access—how organizations manage access over time, review whether users still need access, and control powerful administrative privileges.

Next: Identity Governance and Privileged Access →