How to Migrate Applications from Secrets in Microsoft Entra ID 

You know how it is, you’re developing an app, everything’s going great guns, and then it’s time for it to authenticate. So, you do what many of us have done at some point: you stick a client secret into a config file or hardcode it into a script! 

The problem? Secrets don’t stay secret for long. And attackers know that.  

That’s exactly why Microsoft is pushing us to move away from secret-based authentication. For this, Microsoft Entra offers a suite of modern authentication methods that can greatly improve your application security. 

So, in this blog, I’ll walk you through why it matters, what’s really at stake, and how to move your apps away from secrets. 

Problems with Using Secrets in Applications 

Secrets might feel like the easy way to handle authentication, but they come with way too much baggage. They have more trouble than they’re worth! 

1. Secrets Leak. A Lot: Whether it’s hardcoded in your app, left in a config file, or accidentally pushed to a repo, secrets find a way to leak! Secrets have a nasty habit of slipping out, and when they do, attackers are quick to pounce.  

2. They’re a Pain to Manage: Rotating secrets, tracking where they’re used, and ensuring they’re updated everywhere is exhausting! One missed update can break your entire app.  

3. They Don’t Scale Well: As your app grows and spans across more teams or environments, secrets become even messier. Manual processes invite mistakes like weak secrets, missed rotations, or bad access configs.  

4. Compliance Gets Tricky: Auditors love to ask where your secrets are stored, how often they’re rotated, and who has access. If you don’t have a clean answer, there is a possibility for a compliance fail. 

5. Attackers Love Them: If an attacker gets hold of your app’s credentials, they can impersonate it, gain elevated access, and quietly escalate privileges. 

Bottom line: Secrets are outdated and risky! With smarter, safer authentication options available, there’s really no reason to keep relying on them. 

Use Token-based Authentication for Applications 

Modern authentication makes your apps safer, easier to manage, and built for scale. By shifting to token-based methods like Managed Identities, Federated Identity Credentials, and adding Conditional Access, you shrink your attack surface and tighten up security. 

1. Use managed identity 
2. Use Conditional Access for workload identities 
3. Try Federated Identity for CI/CD Workflows 
4. Application Authentication Policies- Set the Rules 

Ideas to Move Away from Secret-based Authentication for Applications in Microsoft 365 

Example: You’ve got an Azure Function app that’s using a client secret to connect to Microsoft Graph API. You want to ditch the secret and go with something secure. Here’s how you can do it: 

Enable Managed Identity: 

One of the most significant advancements is the concept of managed identities for Azure resources. This lets apps running on Azure securely connect to other cloud services without handling any credentials.  

• Azure automatically creates and rotates these identities behind the scenes, so developers no longer need to store secrets in code.  
• Plus, managed identities work smoothly with other Azure services that support Microsoft Entra, making them a secure and hassle-free option for cloud-hosted apps. 

Assign the Right Permissions: 

Once your app has a managed identity, you need to give it the right access. 

1. Go to Microsoft Entra ID > Enterprise Applications > Your App. 
2. Assign the required Microsoft Graph permissions. 
3. Use Role Assignments to give this identity access to the specific resources it needs. 

Use Conditional Access for Workload Identities: 

Furthermore, Microsoft Entra ID allows for the deployment of Conditional Access policies for workload identities. This lets you define rules like: 

• Only allow access from specific IP ranges 
• Block access if Microsoft Entra detects suspicious activity 
• Require extra conditions for access to sensitive resources 

Example: You can block access to sensitive resources from IPs outside your organization, even if an app’s identity is compromised. 

Try Federated Identity for CI/CD Workflows: 

Another powerful technique is the use of federated identity for service accounts. If you’re using GitHub Actions or any CI/CD pipelines, this one’s a great help! Instead of storing a secret in your pipeline, use Federated Identity Credentials. 

• Establish trust between Microsoft Entra ID and your external identity provider (like GitHub) 
• Your workflow authenticates directly—no secrets involved. 

Application Authentication Policies- Set the Rules: 

Beyond secure storage, Microsoft Entra ID offers application management policies. These policies allow IT administrators to centrally enforce best practices for application configurations, such as 

• Block the use of password-based secrets entirely 
• Limit how long a secret can stay active 
• Enforce organization-wide best practices for all apps 

This provides a consistent and manageable way to implement security standards across the application landscape. 

Bonus: Use Azure Key Vault (When Needed) 

While the goal is to eliminate secrets, there are cases where you still need to store sensitive info. That’s where Azure Key Vault comes in. 

While not always a direct replacement for all types of secrets, it offers a secure and centralized repository for storing and managing cryptographic keys and secrets used by cloud applications and services! 

• Securely store secrets, tokens, or keys 
• Control access with RBAC and policies 
• Let your app access them safely—without hardcoding anything 

Key Vault simplifies the management while keeping your secrets protected. 

Migrating to Token-based Authentication: 

Let’s consider a common scenario: an organization has developed a custom internal web application that needs to access user profile information from Microsoft Graph. Currently, this app uses a service principal with a static password to authenticate to Microsoft Graph. This password needs to be securely stored, rotated regularly, but poses a significant risk, if compromised! 

To migrate this application to a more secure authentication method, the following general steps can be taken: 

1. Identify how it authenticates and what Graph permissions (e.g., User.Read.All) it needs. 
2. If the app runs on Azure (App Service, VM, etc.), enable managed identity from the Azure portal. 
3. Grant the managed identity Graph API access and update the app code to use it via Azure SDKs. 
4. If a full migration isn’t feasible yet, store secrets in Azure Key Vault instead of code or config files/hard coding it. 
5. Restrict access based on IP/location to further protect workload identities. 
6. Once managed identity works, retire the old service principal password to reduce exposure. 
7. Lastly, set up ongoing monitoring and regularly check the app’s authentication health. 

Finally… 

Secrets are just too risky to rely on these days—and the good news is, Microsoft gives us everything we need to make the shift smooth and secure. From managed identities and Conditional Access policies to secret scanning and policy enforcement, the tools are all there. 

If you’ve been putting this off, now’s a great time to start small. Begin with one app, try out a managed identity, play with Conditional Access. You’ll quickly realize how much simpler and safer your setup becomes!