Block the Creation of Client Secrets in Microsoft Entra Application

On Day 2 of Cybersecurity awareness month, learn to restrict new client secret creations in Microsoft Entra applications today. Stay tuned for upcoming blogs in our 31-day Cybersecurity blog series.

Passwords, also known as client secrets, are one-way applications can authenticate to a tenant, similar to how a certificate works. However, Microsoft recommends not to use password credentials whenever possible due to security risks. Curious to know them? That’s exactly what we’re going to cover in this blog, so keep reading. Let’s take a complete walkthrough, from what a client secret is, to the risks it poses, and finally, how to restrict the addition of new passwords. This helps you strengthen your Microsoft 365 environment and move closer to Zero Trust principles.

Application secrets are randomly generated string values created by Entra ID to allow an application to authenticate to a Microsoft Entra resource. At the time of creation, these secrets are displayed in plain text and are later hidden with masked values like ***.

A client secret can have a maximum lifetime of 730 days. When an application requests access to a resource, it sends its client secret along with the client ID and tenant ID to Entra. Entra ID then validates these credentials and, if they are correct, issues an access token to the application, allowing it to access the requested resource.

The application secrets are often hard-coded in scripts used for testing, development, or automation, and sometimes stored as plain text by admins due to their “invisible” nature. This makes them easy to mismanage and compromise.

An admin creates a new client secret with a long-term expiry. Later, that secret gets hard-coded into a script and shared, without anyone realizing the risk. At first, it seems harmless, just a quick way to keep processes running.
But the reality is far more dangerous. If an attacker obtains that script and already knows your tenant ID and app ID, they can obtain access to your tenant resources.

And it gets worse:

• Every action the attacker takes looks like it came from the app—not a real person. Tracing the true actor? Nearly impossible.
• Client secrets don’t just expire overnight. They can live up to expiry date, so once compromised, they offer attackers a long-term backdoor for several months into your tenant.

And that’s why client secrets are more than a minor risk. They are a dangerous loophole:

• Easy to leak
• Hard to trace
• Completely out of step with Zero Trust

Understanding these risks makes it clear why relying on client secrets for Entra applications and service principals can be highly dangerous. From accidental exposure to stealthy attacks and privilege escalation, the potential impact on your Microsoft 365 environment is significant.

The good news is that you don’t have to accept these risks. By restricting the creation of client secrets, you can significantly reduce your attack surface.

So, you’re convinced it’s time to close this loophole and enhance app security in Microsoft 365. Great! Now, let’s get our hands dirty.

The most effective way to enforce restrictions is by configuring Entra ID app management policies. These policies let you apply rules such as password restrictions and asymmetric key restrictions across all applications, service principals, or specific ones. This gives you centralized control and ensures your environment follows consistent security standards.

Let’s walk through the steps to enforce the restriction of password addition for applications using Entra admin center.

Requirement: To manage Microsoft Entra application policies, you need to have any of the following roles:

• Global Administrator
• Security Administrator and Cloud App Administrator
• Application Administrator

Follow each step in sequence to enforce password restrictions for Entra applications.

• Enable client secret restriction policy in Entra ID
• Restrict client secret creation with Entra application policies
• Save the app management policy in Microsoft Entra

Enable Client Secret Restriction Policy in Microsoft Entra

You can enable the Entra ID password restriction application policy using the steps below.

• Sign in to the Microsoft Entra admin center.
• In the navigation pane, click Entra ID and select Enterprise apps.
• Under Security, choose Application policies.
• Click Block password addition under “Password restrictions” and set the status to ON.

Restrict Client Secrets Creation with Entra Application Policies

After enabling the restriction, define which applications the policy applies to. Entra allows you to enforce the restriction in three different modes under Applies to, so you can tailor the policy to all applications, specific apps, or all apps with exclusions.

• All applications – Restrict the addition of new passwords for all application registrations and service principals in your M65 tenant.
  
• All applications with exclusions – Enforce password restrictions for all apps and users except those you specify. To manage user or service app exceptions, you must have both the Attribute Definition Administrator and Attribute Assignment Administrator roles.
  • When you want to exclude specific applications from the password restriction policy, click Add Applications under Excluded Apps, select the apps to exclude, and click Select.
    
  • If you want to allow specific users to create passwords across all apps while blocking others, click Excluded Callers, select the users to exclude, and click Select.
    
    Note: We faced an issue when giving this option a try. We tried creating client secrets with the excluded user, but the creation was still blocked, just like for everyone else. We then tried creating a new application and adding client secrets there, and even tested using a custom security attribute—but in all cases, the restrictions remained in place.
• Select applications – Restrict password creation only for specific applications.
  • If you have chosen this option, click Add applications and pick the apps that should be affected, then click Select.
    

Save the Microsoft Entra Application Policy

• If needed, choose a date under Only apply to apps created after to restrict new passwords only for apps created after that date.
  Note: This option is only available when you select All applications or All applications with exclusions.
• Click Save and close to apply the password restrictions.
  
  
  

Note: These restrictions only prevent the creation of new passwords for applications and service principals. To remove existing passwords, you’ll need to manually remove the password credentials in Entra applications.

If you only want to prevent user-generated application passwords, you can define the Block custom passwords policy. This allows users to create system-generated client secrets in the Entra admin center or via PowerShell, while blocking only the passwords created manually.

When an admin tries to create a client secret for an application or service principal in the Entra admin center, they will see the following error on the creation page. The error indicates that the client secret cannot be created due to policy restrictions.

“Client secrets are blocked by a tenant-wide policy. Contact your tenant administrator for more information.”

Now that you’ve restricted client secrets, the next step is to ensure your applications can still authenticate securely. Microsoft strongly recommends moving away from password-based authentication and adopting more secure alternatives.

Here are the primary options:

1. Managed Identities – These are the strongly recommended option whenever possible. This is the most secure method because you don’t need to manage credentials manually, as they won’t be accessible to users. Applications running in Azure can use managed identities to authenticate to Microsoft 365 services automatically. Azure handles the credentials behind the scenes, eliminating the risk of accidental exposure or mismanagement.
2. Federated Authentication – If your application doesn’t run on Azure, consider using federated credentials from a trusted external identity provider. This allows your app to authenticate securely without storing client secrets, as authentication is handled through the federated platform.
3. Certificate-Based Authentication – Use certificates in scenarios where managed identities or federated credentials are not possible. Certificates are significantly harder to compromise than client secrets. Store certificates securely in a key vault, and whenever possible, use certificates issued by a trusted certificate authority rather than self-signed certificates.

By adopting these alternatives, you reduce the risk of compromise, simplify credential management, and improve auditing. This approach aligns with Microsoft’s best practices and Zero Trust principles.

We hope this post has helped you understand the hidden risks of client secrets and why it’s crucial to tighten control over application credentials. By restricting password additions and adopting safer alternatives like managed identities or certificates, you’re taking a big step toward a stronger, more resilient Microsoft 365 environment.

Thanks for following along! This is just Day 2 of our Cybersecurity Awareness Month series, and there’s plenty more ahead. Stick around for more practical tips, actionable strategies, and insights to strengthen your security every day against evolving threats.