Securing cloud-based service accounts
There are three types of service accounts native to Microsoft Entra ID: Managed identities, service principals, and user-based service accounts. Service accounts are a special type of account that is intended to represent a non-human entity such as an application, API, or other service. These entities operate within the security context provided by the service account.
Types of Microsoft Entra service accounts
For services hosted in Azure, we recommend using a managed identity if possible, and a service principal if not. Managed identities can't be used for services hosted outside of Azure. In that case, we recommend a service principal. If you can use a managed identity or a service principal, do so. We recommend that you not use a Microsoft Entra user account as a service account. See the following table for a summary.
| Service hosting | Managed identity | Service principal | Azure user account |
|---|---|---|---|
| Service is hosted in Azure. | Yes. Recommended if the service supports a Managed Identity. |
Yes. | Not recommended. |
| Service is not hosted in Azure. | No | Yes. Recommended. | Not recommended. |
| Service is multi-tenant | No | Yes. Recommended. | No. |
Managed identities
Managed identities are secure Microsoft Entra identities created to provide identities for Azure resources. There are two types of managed identities:
System-assigned managed identities can be assigned directly to an instance of a service.
User-assigned managed identities can be created as a standalone resource.
For more information, see Securing managed identities. For general information about managed identities, see What are managed identities for Azure resources?
Service principals
If you can't use a managed identity to represent your application, use a service principal. Service principals can be used with both single tenant and multi-tenant applications.
A service principal is the local representation of an application object in a single Microsoft Entra tenant. It functions as the identity of the application instance, defines who can access the application, and what resources the application can access. A service principal is created in (local to) each tenant where the application is used and references the globally unique application object. The tenant secures the service principal's sign-in and access to resources.
There are two mechanisms for authentication using service principals—client certificates and client secrets. Certificates are more secure: use client certificates if possible. Unlike client secrets, client certificates cannot accidentally be embedded in code.
For information on securing service principals, see Securing service principals.
Next steps
For more information on securing Azure service accounts, see: