The Credential Sprawl Problem

Open your Azure portal, navigate to Microsoft Entra ID, and look at your App Registrations. How many are there? Fifty? Two hundred? A thousand?

Now the harder question: for each one, do you know who created it, what it’s used for, whether its credentials have expired, and what would break if you deleted it?

In most tenants, nobody can answer that for every app. App Registration credentials are one of the most under-managed aspects of Azure security. They’re easy to create, rarely documented, and almost never cleaned up. The result is credential sprawl: a growing collection of secrets and certificates spread across your tenant, with unclear ownership and inconsistent lifecycle management.

Why App Registrations Are Different

Key Vault secrets are at least centralised by design. You know which vaults exist, you can list their contents, and you can set access policies. App Registration credentials are different in several important ways:

They live in Entra ID, not Key Vault. This means they’re managed through Microsoft Graph, not the Key Vault data plane. Different APIs, different RBAC model, different monitoring tools.

Almost anyone can create them. By default, every user in an Entra tenant can register an application and add secrets to it. Application Administrators and Cloud Application Administrators can add credentials to any App Registration, and Microsoft warns that they can then act as that application.

They’re created through multiple channels. Azure Portal, Azure CLI, PowerShell, Terraform, ARM templates, and Microsoft Graph directly. There’s no single audit trail for credential creation across all channels.

They have no built-in lifecycle management. Key Vault has rotation events, expiry notifications, and soft-delete protection. App Registration credentials have an expiry date field. That’s it. No notifications, no automatic rotation, no cleanup.

The Anatomy of a Credential Leak

Here’s a pattern we see repeatedly:

  1. A developer creates an App Registration for a microservice integration
  2. They generate a client secret with a 2-year expiry
  3. The secret is stored in a Key Vault and referenced by an App Service
  4. Six months later, the developer leaves the organisation
  5. Eighteen months later, the secret expires
  6. The App Service starts failing authentication to downstream APIs
  7. The on-call team scrambles to figure out which App Registration is affected, what it does, and how to create a new secret without breaking other consumers of the same App Registration

This scenario plays out constantly. The mean time to resolution is often measured in hours, not because the fix is complex, but because nobody knows the dependency graph.

Mapping the Dependency Graph

The first step toward controlling credential sprawl is understanding what depends on what. For each App Registration, you need to know:

  • What APIs does it access? Check the API Permissions blade to see delegated and application permissions
  • Where are its credentials stored? Check Key Vaults across all subscriptions for secrets that correspond to this App Registration’s client ID
  • What applications consume it? Check App Service and Function App configurations for Key Vault references or direct credential references
  • Who owns it? Check the Owners property in Entra ID, though this is often empty or outdated

Building this map manually is possible but painful. Microsoft Graph provides the raw data:

# List all App Registrations with credential details
az ad app list --all --query "[].{
    appId: appId,
    displayName: displayName,
    secretCount: length(passwordCredentials),
    certCount: length(keyCredentials),
    secrets: passwordCredentials[].{
        hint: hint,
        start: startDateTime,
        end: endDateTime
    },
    owners: owners
}" -o json

For a large tenant, this returns a wall of JSON. You need tooling to make it actionable.

Lifecycle Management Strategies

Strategy 1: Enforce Short-Lived Credentials

Application management policies let you cap credential lifetimes or block new client secrets altogether. You set them through Microsoft Graph or Graph PowerShell rather than the portal. Microsoft’s own recommendation is to block new client secrets and cap certificates at 180 days. If you can’t go that far yet:

  • Set maximum client secret lifetime to 180 days (or less)
  • Require certificate-based credentials for production applications (certificates are generally more secure than client secrets)
  • Use Managed Identities wherever possible to eliminate credentials entirely

Managed Identities are the ideal solution when the consuming application runs in Azure. They eliminate credential management altogether. No secrets to rotate, no certificates to renew, no risk of credential exposure. Use them for App Services, Functions, Container Apps, VMs, and any other Azure compute that supports them.

Strategy 2: Centralise Credential Storage

Even when App Registrations are the identity provider, their credentials should be stored in Key Vault:

  1. Create the client secret on the App Registration
  2. Immediately store it in a designated Key Vault
  3. Configure consuming applications to reference the Key Vault secret, not the raw credential
  4. Never store App Registration secrets in application configuration files, environment variables, or CI/CD pipeline variables

This gives you Key Vault’s monitoring, access logging, and soft-delete protection, none of which exist for credentials stored elsewhere.

Strategy 3: Implement Automated Rotation

Manual rotation doesn’t scale. For App Registration secrets, automated rotation involves:

  1. Generate a new client secret via Microsoft Graph API
  2. Store the new secret as a new version in Key Vault
  3. Wait for the overlap window (both old and new credentials valid simultaneously)
  4. Propagate to consuming applications (restart App Services, update Container App revisions)
  5. Verify that consumers are using the new credential
  6. Remove the old credential from the App Registration

This workflow requires orchestration across Microsoft Graph, Key Vault, and Azure Resource Manager, which is three different APIs with different authentication requirements. Building this yourself is certainly possible, but it’s a meaningful engineering investment to handle failure scenarios, retry logic, rollback, and audit logging correctly.

Strategy 4: Continuous Discovery and Monitoring

Even with good hygiene, new credentials get created. You need continuous monitoring to catch:

  • New App Registrations created without following naming conventions or ownership requirements
  • Credentials added outside of your rotation pipeline, e.g., a developer manually adding a secret through the portal
  • Approaching expiry dates that haven’t been picked up by rotation automation
  • Orphaned App Registrations that no longer serve a purpose but still have valid credentials

The CertifyClouds Approach

CertifyClouds tackles App Registration credential sprawl as part of its unified secret lifecycle platform:

Discovery scans your entire Entra ID tenant to inventory every App Registration, its credentials (secrets and certificates), expiry dates, and ownership. Each credential is matched to the Key Vault secret that holds it, so you can see which ones aren’t stored in a vault at all.

Dependency mapping traces the connection from App Registration to Key Vault secret to consuming App Service / Function / Container App. When you rotate a credential, you see exactly what will be affected.

Automated rotation handles the full workflow: generate new credential, store in Key Vault, propagate to consumers, verify, and clean up the old credential. Zero-downtime overlap windows are configurable per secret.

Compliance scoring checks the estate against discovery, rotation and dependency-mapping rules. A credential with no recorded dependency shows up as a gap to investigate, since it may still be in use somewhere CertifyClouds can’t see.

Sign-in and policy checks show which App Registrations sign in with a federated credential (GitHub Actions, Azure DevOps, GitLab, Kubernetes or a managed identity) and flag any that still hold a client secret. With one extra read-only permission, CertifyClouds also checks whether your tenant’s app management policy caps or blocks new client secrets and caps certificate lifetimes for new apps, the controls from Strategy 1.

Start Small, Think Big

Credential sprawl isn’t solved overnight. Start with these concrete steps:

  1. Inventory: run az ad app list --all and count how many App Registrations have expired or expiring credentials. The number will likely surprise you
  2. Triage: identify which App Registrations are used in production and prioritise those for lifecycle management
  3. Migrate to Managed Identities where possible. Every App Registration you eliminate is one less credential to manage
  4. Centralise remaining credentials in Key Vault with expiry tracking
  5. Automate rotation for the highest-risk credentials first

Or skip the spreadsheet phase: CertifyClouds lists every App Registration, its credentials and the resources that depend on them from a single scan. Start with a free 30-day trial.

Further Reading