Client Secrets
Menu path: Observe → Application Governance → Client Secrets
URL: /en/insights/dashboard/appGov/client-secrets
Purpose
The Client Secret Management page tracks all client secrets associated with application registrations in your Entra ID tenants. Client secrets are essentially passwords for applications - they allow an application to prove its identity to Entra ID and obtain access tokens. Unlike human passwords, client secrets are often embedded in application configurations, CI/CD pipelines, key vaults, or hard-coded in code.
This page surfaces the good (healthy secrets with adequate lifetime remaining), the bad (secrets approaching expiry that need planned rotation), and the ugly (secrets that have already expired - indicating either failed applications or ungoverned credential sprawl).
Client secret management is a critical operational discipline. Unlike certificates, secrets tend to proliferate over time as developers create new secrets without removing old ones, leading to credential sprawl. Each secret is an attack surface - if leaked, it grants full application-level access to whatever permissions the application holds.
Observation Cards
Total Client Secrets
What it means: The total inventory of client secrets across all managed applications. This is surprisingly small for an estate of 656 applications - most applications in this environment either use certificates, are Microsoft-managed (no secrets needed), or have no credentials at all. Only custom/in-house applications typically have client secrets.
Critical: Expiring in 15 Days
What it means: 4 secrets on actively-used applications expire within 15 days and require immediate rotation.
Why it matters: These secrets are an operational emergency. If not rotated before expiry, the applications they serve will stop authenticating with Entra ID. Check whether these applications have any pending maintenance windows, and if not, initiate emergency rotation procedures.
Expiring Within 90 Days
What it means: 1 additional secret (beyond the critical 15-day window) expires within 90 days.
Active & Expiring (90d)
What it means: The secret expiring within 90 days belongs to an actively-used application - confirming the renewal is needed to prevent a service outage.
Charts
Secret Lifecycle Compliance
Chart type: add example --> Time-series line chart with two series
What it shows: Over time, the cumulative count of secrets created that are within your maximum lifetime policy (green line) versus those that exceed the maximum (red line).
In the example, the red line consistently exceeds the green line, indicating that more secrets have been created with lifetimes exceeding policy than within policy. This is the "ugly" finding for this chart.
Why it matters: Microsoft recommends client secrets have a maximum lifetime of 1-2 years (and ideally shorter - 6-12 months). Secrets with very long lifetimes (2+ years) have a larger window of exposure if leaked. If the "Exceeds Max Lifetime" line is growing faster than the "Within Max Lifetime" line, your secret issuance process is creating compliance violations.
What to do: Establish and enforce a maximum secret lifetime policy in your application registration process. Identify all existing secrets that exceed the policy maximum and rotate them to new, policy-compliant secrets.
Upcoming Secret Expirations
Chart type: add example --> Timeline/bar chart
What it shows: When secrets are due to expire, plotted over time, allowing you to see whether multiple secrets expire simultaneously.
Why it matters: Like the certificate expiry chart, this helps with rotation planning. If many secrets expire in the same month, you need to plan resources and change windows accordingly.
The Client Secrets Table
The table lists all client secrets with the following columns:
- Application - The application this secret belongs to
- Name - The secret's name/description
- Days Until Expiry - Days remaining (negative = already expired)
- End Date - The expiry date
- Last Activity - When the application last signed in
- Urgency - Expired, Expiring 90d, Healthy
- Is Active - Whether the application has recent sign-in activity
- Exceeds Max Lifetime - Whether the secret was created with a lifetime exceeding policy
- Renew - A direct action link to initiate rotation
Reading the table - what the data tells you
From the example data, several findings are visible:
Already expired secrets (negative Days Until Expiry): The table shows 9 secrets that are already expired, including ones belonging to P2P Server (637 days past expiry), Test Directory Read Write All, and various Apporetum integration applications. Expired secrets on inactive applications represent ungoverned credential debt. Expired secrets that were previously active (as shown by "Last Activity" dates) may indicate application outages that have already occurred.
Healthy secrets that exceed max lifetime: Several secrets show "Exceeds Max Lifetime: Yes" despite being in a "Healthy" urgency state - meaning they won't expire soon, but they were created with an overly long lifetime. These should be rotated to shorter-lived replacements as part of lifecycle hygiene.
Applications with multiple secrets: Multiple rows for the same application (e.g., Apporetum Marketplace Deployer has both expired and healthy secrets) indicate that old secrets have not been cleaned up after rotation. Unused expired secrets should be deleted from application registrations even after rotation to reduce the attack surface.
Best practices surfaced by this report
- Rotate before expiry - Never let a secret expire on an active application
- Delete after rotation - Remove old secrets after creating new ones
- Apply maximum lifetime policies - Create secrets with the shortest practical lifetime
- Use Key Vault - Where possible, use Azure Key Vault to manage secret rotation automatically
- Regular audit - Review this report monthly to stay ahead of expirations