# Applications don't have client secrets configured

Applications that use client secrets might store them in configuration files, hardcode them in scripts, or risk their exposure in other ways.

Source: https://maester.dev/docs/tests/ZTA.21772

<!-- This file is generated by website/scripts/generate-test-docs.mjs. Do not edit manually. -->

:::note[Maester checks this too]
[MT.1057](/docs/tests/MT.1057) (App registrations should no longer use secrets.) checks the same setting. Running both reports it twice.
:::

## Overview

Applications that use client secrets might store them in configuration files, hardcode them in scripts, or risk their exposure in other ways. The complexities of secret management make client secrets susceptible to leaks and attractive to attackers. Client secrets, when exposed, provide attackers with the ability to blend their activities with legitimate operations, making it easier to bypass security controls. If an attacker compromises an application's client secret, they can escalate their privileges within the system, leading to broader access and control, depending on the permissions of the application.

Applications and service principals that have permissions for Microsoft Graph APIs or other APIs have a higher risk because an attacker can potentially exploit these additional permissions.

## Remediation

- [Move applications away from shared secrets to managed identities and adopt more secure practices](https://learn.microsoft.com/entra/identity/enterprise-apps/migrate-applications-from-secrets?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci).
   - Use managed identities for Azure resources
   - Deploy Conditional Access policies for workload identities
   - Implement secret scanning
   - Deploy application authentication policies to enforce secure authentication practices
   - Create a least-privileged custom role to rotate application credentials
   - Ensure you have a process to triage and monitor applications

## Run it

The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:

```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```

Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.

<details>
<summary>About this check</summary>

| | |
| --- | --- |
| Severity | High |
| Effort to fix | Medium |
| Impact on users | Low |
| Pillar | Identity |
| Category | Application management |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Applications |
| Area | Applications and workload identities |
| ATT&CK | [T1552](/docs/tests?mitre=T1552) Unsecured Credentials, [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts |
| Licence | Free |
| Tenant | Workforce, External |

Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.

</details>

<p class="mt-ms-note not-content"><svg class="mt-ms-note__logo" viewBox="0 0 21 21" aria-hidden="true"><rect width="10" height="10" fill="#f25022"/><rect x="11" width="10" height="10" fill="#7fba00"/><rect y="11" width="10" height="10" fill="#00a4ef"/><rect x="11" y="11" width="10" height="10" fill="#ffb900"/></svg><span>A Microsoft check, part of the <a href="/docs/tests/packs/zero-trust-assessment">Zero Trust Assessment</a> pack. Text from ZeroTrustAssessment 3.1.0, © Microsoft, <a href="/docs/tests/packs/zero-trust-assessment#licence">MIT licence</a>.</span></p>
