Support Asked for a New App Secret. What Would That Enable?

Before replacing an application’s credential, check who will receive it and what access the application already has. A maintenance request can create a new way to use existing permissions without adding any permissions at all.

Consider a fictional support request: a reporting job has stopped, and the contact asks its owner to create a replacement client secret and send it to an address supplied in the ticket. The owner needs to verify both the repair and the credential’s destination.

Start with the application’s identity

In Microsoft Entra ID, an application registration describes an application. A service principal represents that application in a particular tenant and participates in its access configuration. A familiar display name is a poor substitute for the application identifier and tenant when reviewing a change. Microsoft: applications and service principals

A client secret is a credential a confidential application can use to authenticate. It is not an employee’s password, and it is not an access token. Microsoft documents certificates and other supported credentials as alternatives to secrets, with managed identities preferred where applicable. Microsoft: application credential guidance

For the support request, write down the exact application, its operational owner, and the system that normally holds its credential. These three facts expose different mistakes. The request might name the wrong app, reach someone who cannot authorize its maintenance, or send a genuine credential to an unauthorized destination.

The relevant privilege is the ability to change that app’s credentials. Microsoft’s role reference explicitly warns that an administrator able to add credentials can assume an application’s identity and use access already granted to it. Application owners can also manage credentials of apps they own. Microsoft: role permissions and credential-management warnings

That makes the app owner a meaningful social-engineering target even when they are not a global administrator.

Four terms that change the decision

Keep the following distinctions in the change record:

In the client credentials flow, software authenticates as itself, without a signed-in user. Microsoft does not issue refresh tokens in this flow. The client can request another access token using its credential. The resource then enforces authorization for the requested action. Microsoft: client credentials flow

Adding a secret does not turn delegated permission into application permission. It also does not add a new mailbox or file permission. The danger in this example is that an unauthorized holder could authenticate as an application whose existing authority is useful to them. Review that authority before treating the change as harmless maintenance.

Our consent phishing guide covers the decision to grant permission. This article begins later, with an application already in use. Our integration-token incident guide covers a supplier-side credential compromise. Here, the owner is being asked to create a new credential deliberately.

What Midnight Blizzard did with application access

Microsoft’s January 2024 Midnight Blizzard investigation described compromise and abuse of OAuth applications, including a legacy test application with elevated access. The actor created additional applications and used application access to collect corporate email through Exchange Web Services. Microsoft Threat Intelligence: January 25, 2024 investigation

That report establishes the significance of application identity in a real intrusion. It does not establish that the actor used the fictional support request in this article. Nor should its historical Exchange permissions be copied into a current implementation without checking today’s platform guidance.

An investigation that stops at the compromised employee account can miss changes to software identities. Review the application’s credentials, authority, ownership, and operational history too.

Diagnose the failure before replacing the credential

Start with the existing maintenance record. Does the platform team have an incident for this job? Does the configured credential’s expiration fit the claimed failure? Who normally deploys replacements? Reach the platform team through the established directory, rather than a second contact supplied in the request.

A confirmed outage does not confirm the proposed diagnosis. If the credential has not expired, replacing it needs another explanation. The service owner should establish how the proposed change addresses the failure before approving it.

Credential custody is a separate question. The replacement belongs in the workload’s approved storage and deployment process. A support-chat recipient is not automatically part of that process. A vendor may be able to diagnose the problem without possessing the application’s credential.

Read the change ticket as a future incident responder

A ticket that says “rotated secret” leaves several questions unanswered. Did someone add a second credential or replace the old one? Which application was changed? Was the new credential delivered to the expected workload? Who checked that the intended job resumed?

The change record should identify:

• The application and tenant identifiers, plus a link to the owned service record.
• The diagnosed failure and the person who independently confirmed it.
• The credential reference and intended lifetime, without its secret value.
• The approved storage and deployment destination.
• The person responsible for removing superseded credentials and verifying recovery.

These are proposed review fields, not Microsoft audit properties. They let a responder see who approved the change without putting the secret in the ticket.

The record should also capture an explicit dependency: which production task would stop if the application were suspended? That answer helps responders weigh containment quickly. It does not justify leaving an unexplained credential active while the team searches for its owner.

If the credential was already added

Bring the identity administrator and workload owner into the same investigation. Preserve the request, relevant change records, and credential identifiers under your incident process. Avoid circulating the secret value in the investigation thread.

Microsoft’s application security-operations guide recommends monitoring added credentials, changes outside normal workflows, permission changes, and owner changes. It identifies Entra audit logs as a source for credential updates. An investigation should therefore include the application’s configuration history, not just its current display name. Microsoft: application monitoring

Then check service-principal sign-ins. Microsoft separates these from interactive and non-interactive user sign-ins. Looking only at the employee’s sign-in history can miss the relevant application authentication records. Microsoft: sign-in log types

Suppose the team finds a credential addition, followed by a successful application sign-in, followed by a reporting-API request outside the nightly schedule. That sequence warrants investigation. It does not identify the operator merely because the records name the reporting application.

Compare the request with the legitimate workload’s execution history. Was there an approved retry? Did the platform team perform a maintenance check? If neither explains the activity, the API owner should inspect the operation and its result. A rejected request and a completed report export lead to different conclusions about exposure.

This is also where collection limits matter. If the API retains request metadata but not response content, the team should explain what can be reconstructed. Do not silently convert missing detail into a statement that no data left the service.

Contain the app path and restore the job separately

Have the incident lead approve the containment action with the application owner. Review the suspicious credential, any additional credentials, permission changes, and unexpected owners. A replacement issued into the same untrusted custody path would repeat the original problem.

Deleting a secret is a change to an authentication credential. Do not describe that action as proof that every previously issued access token has stopped working. Access tokens have their own validity and resource-validation behavior; establish the relevant resource’s response and monitoring plan with its owner. Microsoft: access-token validation and lifetime

Likewise, resetting the employee’s password does not document removal of an application credential. Record the app action explicitly. If the operator account was compromised, its remediation is an additional workstream, not a substitute.

For a planned exercise, use a disposable app and harmless test resource under separate technical authorization. Define the expected credential-change event, application sign-in, resource response, and cleanup before starting. A conversation-only exercise can instead stop when an employee requests the independent approval; it should not require a live production secret.

Before closing the repair, check that the intended job runs with the right permissions and that its credential is stored and deployed through the approved process. The platform owner should record that result and the status of obsolete credentials. “The report arrived” is useful operational evidence, but it does not answer every remaining investigation question.

Check whether the workload still needs a shared secret

For longer-term design, ask the platform owner whether the workload supports managed identity, workload identity federation, or certificate-based authentication under current guidance. Those options still need ownership and configuration review; replacing a secret does not remove the need to verify who is requesting a change.