Skip to main content
Version: Angophra

Application Governance Overview

Menu path: Observe → Application Governance → Overview
URL: /en/insights/dashboard/appGov/overview

Purpose​

The Application Governance Overview is the executive summary for your non-human identity estate. While the Deep Dive section focuses on human identities and their accounts, Application Governance focuses on the non-human entities in Entra ID: application registrations, enterprise applications (service principals), managed identities, and the credentials, permissions, and assignments that govern their access.

This overview page surfaces the most critical risk indicators across your entire application estate, organised into three sections: Onboarding (how applications are entering your environment), Operations (immediate operational risks requiring action), and Governance (strategic risk posture and access control patterns).

Think of this page as asking: "What non-human entities exist in my tenant, are they being managed, and are any of them about to break or causing a security risk?"

Filters​

  • In Scope - Toggle to show only applications that have been marked as in-scope for governance
  • Data Source - Filter by connected Entra ID tenant

Onboarding Section​

Application Portfolio Breakdown​

Chart type: add example --> Donut chart
What it shows: The total application estate (656 in the example) broken down by service principal type: Application, ManagedIdentity, SocialIdp.

Why it matters: Understanding the composition of your non-human identity estate is the first step in governing it. The three types represent very different risk profiles:

  • Application - Standard application registrations and enterprise apps. These are the most common and the most varied in terms of risk.
  • ManagedIdentity - Azure-managed identities where Microsoft handles the credential lifecycle. These are generally more secure but still need to be tracked for permission sprawl.
  • SocialIdp - Social identity providers (Google, Facebook, etc.) configured in Entra External ID. These represent external authentication pathways that need governance.

Application Growth & Compliance Trend​

Chart type: add example --> Time-series area chart
What it shows: How the total application count has grown over time (from the beginning of your data history to the present), with a secondary overlay showing how many of those applications are non-compliant.

Why it matters - this is the "ugly" headline. The chart shows whether compliance is keeping pace with growth. If the application estate is growing rapidly but the non-compliant proportion is staying flat or growing, it means new applications are being onboarded without meeting governance standards. A healthy trend would show compliance improving as processes mature; an unhealthy trend shows compliance gaps widening.

What to look for: Is the red (non-compliant) area growing faster than the total application count? This means governance is falling further behind. Are there specific periods of rapid growth where compliance dropped? This may correspond to migration projects or acquisitions.

Compliance Gaps by Onboarding Year​

Chart type: add example --> Bar chart
What it shows: Grouped by the year each application was onboarded (created), how many have unresolved compliance gaps.

Why it matters: This chart tells you whether old applications are the problem or new ones. If applications onboarded in older years dominate the chart, it suggests a legacy backlog problem - applications that predate your governance processes and have never been brought into compliance. If recent years dominate, it suggests your onboarding governance process is not catching issues at the point of creation.

Operations Section​

Certs at Risk of Outage​

KPI: Count of actively-used certificates expiring within 30 days.

Why it matters: A certificate that expires causes authentication failures. If an application is actively used and its authentication certificate expires, the application stops working. This is an operational emergency - not just a security issue. Zero is the target; any value above zero requires immediate action to renew the certificate before the expiry date.

Secrets at Risk of Outage​

KPI: Count of actively-used client secrets expiring within 30 days.

Why it matters: Same as certificates - if an application's client secret expires and has not been rotated, the application cannot authenticate to Entra ID. This causes service outages. Actively-used secrets expiring within 30 days need to be rotated immediately. Zero is the target.

Unused Applications​

KPI: 555 applications with no recorded sign-in activity.

Why it matters: Over half the application estate (555 out of 656 total) has never been used or has no recent activity. These applications represent: shadow IT that was registered but never deployed, abandoned projects, test applications left in production, and third-party integrations that are no longer needed. Every unused application is an attack surface - credentials and permissions that exist but serve no active business purpose. This is a significant "ugly" finding that warrants a systematic decommission programme.

What to do: Review unused applications against a business register. For each unused application, determine: does any business unit still need this? If not, decommission it - disable it, revoke its permissions, and eventually delete it. Reducing the unused application count reduces your attack surface.

Expired Certificates​

KPI: Count of certificates that are already past their expiry date.

Why it matters: Expired certificates may be causing current authentication failures. They also represent a governance failure - the certificate was not renewed before it expired, which could indicate no one owns the renewal process for that application.

Expired Client Secrets​

KPI: Count of client secrets already past their expiry date (9 in the example).

Why it matters: Expired secrets that were previously used by active applications have likely caused outages already. Expired secrets on inactive applications indicate poor credential hygiene - old credentials should be cleaned up even if the application is not currently in use.

Governance Section​

Direct User Assignments​

KPI: 29 individual users directly assigned to applications.

Why it matters: Direct user assignment to applications is an IAM anti-pattern. The preferred approach is group-based access - users are added to a group, and the group is assigned to the application. Direct assignments are harder to audit, harder to revoke en masse, and often persist when a user changes roles. 29 direct assignments is a manageable number to remediate; left unaddressed, this number tends to grow.

What to do: Review each direct assignment. For each user, create or identify an appropriate group, move the assignment to the group, and remove the direct assignment.

Legacy Application Exposure​

Chart type: add example --> Donut chart
What it shows: The proportion of the application estate that relies on legacy service principal types or configurations (e.g., V1 OAuth, outdated authentication protocols).

Why it matters: Legacy applications using older authentication protocols are more vulnerable to certain attack types and may not support modern security features like Conditional Access. The goal is to migrate all applications to modern authentication standards (OAuth 2.0, OIDC).

Dormant Apps with Elevated Privileges​

Chart type: add example --> Donut chart
What it shows: 550 inactive applications that still hold risky permissions, broken down by risk level (Low, High, Critical).

Why it matters - this is one of the most critical governance findings. An application that is dormant (not being used) but still has high or critical permissions represents a significant risk: a dormant application with elevated privileges is effectively a backdoor. If an attacker compromises the application's credentials, they inherit all those permissions - and because the application is dormant, the malicious activity may not trigger any alerts. The combination of "dormant" and "elevated privileges" is the definition of a high-value target for attackers.

What to do: Immediately investigate dormant applications with Critical or High risk permissions. Either reactivate them with appropriate monitoring, remove their elevated permissions, or decommission them.

Access Control Enforcement Trend​

Chart type: add example --> Time-series line chart
What it shows: Over time, how many newly onboarded applications have "Assignment Required" set to true (meaning users must be explicitly assigned before they can access the application), versus "Not Required" (open to all tenant users) or "Unknown".

Why it matters: "Assignment Required" is a critical security control. When it is off, any user in your Entra ID tenant can use the application - even if they should not have access. As new applications are onboarded, you want to see the "Required" line growing and the "Not Required" line shrinking. A predominantly "Not Required" application estate means most of your applications are effectively accessible by any user in the tenant.

The Applications Table​

The table at the bottom lists all service principals with key attributes:

  • Display Name - Application name
  • Principal Type - Application, ManagedIdentity, SocialIdp
  • Enabled - Whether the application is enabled
  • Inactive - Whether the application has recent sign-in activity
  • Microsoft Managed - Whether this is a Microsoft first-party service principal
  • Publisher - The application publisher (where available)
  • Assigned Users - Count of directly assigned users
  • Credentials - Count of credentials (certificates + secrets)
  • Days Since Activity / Last Sign-In - Activity data