I'm building an automation workflow for Microsoft Azure and want to use the Microsoft Graph API where appropriate. The workflow needs to create an application registration, create its service principal, generate and upload a certificate, and create an Azure Bot with its messaging endpoint configured. What is the recommended production approach, and what is the minimum set of Microsoft Entra roles, Microsoft Graph permissions, and Azure RBAC permissions required? I'd like to avoid using Global Administrator and keep the automation identity as restricted as possible.
4 Answers
The Microsoft Graph reference is the best place to confirm the precise permissions because they vary by operation. Check the permission table on the application, service-principal, and credential API pages, then grant only the application permissions needed and obtain admin consent through your normal approval process. Azure CLI, PowerShell, Terraform, or Bicep can all be used alongside Graph; the important part is keeping Entra permissions and Azure RBAC scopes separate.
These tasks span two different management planes. Application registrations, service principals, and app credentials are Microsoft Entra objects managed through Microsoft Graph. The Azure Bot is an Azure resource managed through Azure Resource Manager, not Graph. For an automation identity, Application.ReadWrite.OwnedBy can cover creating applications and managing credentials for applications it owns, which is safer than Application.ReadWrite.All when tenant-wide access isn’t needed. For the bot, use Azure RBAC such as Contributor at the target resource-group scope, or create a custom role limited to the required Microsoft.BotService actions. None of this inherently requires Global Administrator, but verify the exact permissions and tenant consent requirements for your workflow.
Consider whether you need a certificate at all. For workloads running in Azure or in a CI/CD system that supports OIDC, a managed identity or workload identity federation with a federated credential can remove the need to generate, store, rotate, and upload a certificate. If a certificate is required, Microsoft Graph’s documentation for each application and credential operation lists the delegated or application permissions needed, so use those tables to validate the final permission set.
I’d avoid implementing the whole deployment directly against low-level APIs unless there’s a specific reason. Bicep or Terraform works well for the Azure resource side, while Microsoft Graph PowerShell or carefully scoped Graph calls can handle Entra objects. Bicep can provision some Entra-related resources, but its application and service-principal lifecycle support has limitations, so PowerShell or Graph may be easier for certificates and credential management.

That makes sense. I’ll separate the Entra provisioning from the Azure Bot deployment instead of trying to force everything through Graph.