Skip to main content

How to Rotate Compromised Application Secrets in Microsoft 365

Nick
  • Updated

Team: Huntress Managed Identity Threat Detection and Response (ITDR)
Product: Microsoft 365
Environment: Microsoft Entra ID
Summary: Perform a zero-downtime secret rotation in Microsoft Entra ID for Microsoft 365 applications following a credential compromise and verify secret adoption.

In this Article

Verify Application Dependencies

Before making credential changes, identify all background services, daemons, and connection strings using the current secret to ensure zero downtime.

  1. Inventory all internal systems and background services dependent on this application's credentials.
  2. Confirm both production and non-production instances utilizing the secret are identified.

Verification: You have a documented inventory of all systems impacted by the secret rotation.

 

Generate a Second New Secret

Create a new client secret in Microsoft Entra ID while retaining the current active credentials. Having two valid secrets active simultaneously prevents service disruptions during configuration updates.

  1. Log in to the Microsoft Entra admin center.
  2. Navigate to Identity > Applications > App registrations.
  3. Select your application from the list.
  4. In the left navigation menu, select Certificates & secrets.
  5. Select New client secret, enter a description and expiration period, then select Add.
  6. Copy the value of the new client secret immediately and store it securely.

Do not delete either the current secret or the compromised secret during this step.

Verification: The application displays two valid active client secrets simultaneously in Microsoft Entra ID.

 

Update Application Configuration and Confirm Adoption

Deploy the new secret across your application infrastructure to transition authentication seamlessly, then verify that the application is actively authenticating with the new credential.

  1. Deploy the newly generated secret into your application configuration files, environment variables, or secure key vaults (such as Azure Key Vault).
  2. Restart or redeploy the application services so they begin authenticating with the new secret.
  3. Verify that your application is actively using the newly created secret rather than an old or cached credential using one of the following methods:

How to verify that the new Secret is being used. 

Method 1: Check Microsoft Entra Sign-In Logs (Recommended)

Microsoft Entra logs every authentication request made by an Application (Service Principal), including which secret ID was used to acquire a token.

  1. Log in to the Microsoft Entra admin center.
  2. Expand Identity > Monitoring & health, then select Sign-in logs.

    3. Prerequisite: Requires Security Reader or Global Reader role.

  3. Select the Service principal sign-ins tab at the top of the logs view.
  4. Select Add filter, choose Application ID (or Application), and enter your application name or Client ID.
  5. Select the most recent successful sign-in entry.
  6. In the details pane, select the Basic info tab and check the Key ID field.

Verification: The Key ID matches the Key ID (or Secret ID) shown next to your new secret under App registrations > Certificates & secrets.

Method 2: Audit Local Application Logs & Key Vault Metrics

If your application uses Azure Key Vault or standard SDK logging (such as Azure Identity SDK or MSAL):

  • Azure Key Vault Logs: If your application fetches secrets dynamically from Key Vault, review your Key Vault Insights or SecretGet diagnostic logs in Azure Monitor to confirm the app pulled the updated secret version.
  • App Insights / Console Tracing: Search your application logs for authentication events. When using libraries like MSAL or the Azure SDK, enable Information or Verbose logging temporarily to trace token acquisition events and confirm token requests succeed without caching issues.

Method 3: Controlled Secret Invalidation (Soft Cutover Test)

If you have two secrets active in Entra ID (the old compromised secret and the new replacement):

  1. Ensure the application configuration is updated with the new secret.
  2. Temporarily disable or delete the old secret in Entra ID.
  3. Trigger a workflow in your application or restart the service to force a fresh authentication request.

Verification: The application authenticates successfully without throwing unauthorized or expired credential errors (such as AADSTS7000215: Invalid client secret provided) in server logs.

Token Caching Delay: Applications using MSAL or OAuth 2.0 client credentials typically cache access tokens until they expire (usually 60–90 minutes). The application will not present the new secret to Entra ID until its current cached access token expires or the service is restarted.

 

For the Huntress Managed ITDR Microsoft 365 app, rotate credentials through Huntress—not by manually creating a secret in Entra:

  1. Open Huntress → Integrations → Microsoft 365.
  2. Expand the affected tenant.
  3. Select the ⋯ menu → Reauthorize.
  4. Sign in again with a Global Administrator account.
  5. Reapprove the requested permissions.
  6. Confirm the tenant returns to a healthy/onboarded state.

Reauthorization is Huntress’s supported process for refreshing the integration and applying updated application credentials.

If you see an unknown secret on the Huntress app registration, remove only that credential and contact Huntress Support/SOC; do not replace it manually.

 

Revoke Compromised and Old Secrets

Remove the compromised secret and any temporary replacement secrets once the application successfully authenticates with the new secret.

  1. Return to the Microsoft Entra admin center and navigate to Identity > Applications > App registrations > your application > Certificates & secrets.
  2. Locate the compromised client secret and any unused older secrets.
  3. Select Delete (trash icon) next to each compromised or obsolete secret.

Verification: Only the actively used client secret remains listed under Client secrets.

Related articles