# Creating new applications and service principals is restricted to privileged users

If nonprivileged users can create applications and service principals, these accounts might be misconfigured or be granted more permissions than…

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

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

:::note[Maester checks this too]
[CISA.MS.AAD.5.1](/docs/tests/CISA.MS.AAD.5.1) (Only administrators SHALL be allowed to register applications.), [CIS.M365.5.1.2.2](/docs/tests/CIS.M365.5.1.2.2) (Ensure users cannot register applications), [EIDSCA.AP10](/docs/tests/EIDSCA.AP10) (Default Authorization Settings - Default User Role Permissions - Allowed to create Apps.) check the same setting. Running both reports it twice.
:::

## Overview

If nonprivileged users can create applications and service principals, these accounts might be misconfigured or be granted more permissions than necessary, creating new vectors for attackers to gain initial access. Attackers can exploit these accounts to establish valid credentials in the environment and bypass some security controls.

If these nonprivileged accounts are mistakenly granted elevated application owner permissions, attackers can use them to move from a lower level of access to a more privileged level of access. Attackers who compromise nonprivileged accounts might add their own credentials or change the permissions associated with the applications created by the nonprivileged users to ensure they can continue to access the environment undetected.

Attackers can use service principals to blend in with legitimate system processes and activities. Because service principals often perform automated tasks, malicious activities carried out under these accounts might not be flagged as suspicious.

## Remediation

- [Block nonprivileged users from creating apps](https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-app-roles?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)

## 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 | Medium |
| Effort to fix | Low |
| Impact on users | Low |
| Pillar | Identity |
| Category | Application management |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | User and directory settings |
| Area | Applications and workload identities |
| ATT&CK | [T1098.001](/docs/tests?mitre=T1098.001) Additional Cloud Credentials, [T1528](/docs/tests?mitre=T1528) Steal Application Access Token |
| Licence | P1 |
| Tenant | Workforce |

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>
