Entra.Chat

Most Conditional Access gaps aren’t exotic. They come from reading policies the wrong way: as firewall rules with an “allow”, as a list of platforms that seems complete, as an MFA exception for the office that made sense years ago. Brandon Colley has reviewed well over a thousand Conditional Access policies in customer assessments, and the same handful of mistakes come up in tenant after tenant.
Once those are fixed, the risk moves. Passkeys, privileged access and Conditional Access put more locks on the front door, the user sign-in. An app that was consented to years ago, holds a client secret and still has a stale redirect URI is a back door that none of those locks cover.
Brandon is a Senior Security Consultant at TrustedSec and a Microsoft Security MVP. He came from systems administration, learned Active Directory security at Trimarc, and now spends his days on cloud and on-premises assessments and the remediation that follows. These are the gaps he checks first, and the app and consent settings he has moved on to.
Security defaults can cover more admins than your policies
The free tier can be stricter than the paid one. Security defaults require MFA for 16 administrator roles. The Microsoft-managed policy “Multifactor authentication for admins accessing Microsoft Admin Portals”, and the “Require MFA for admins” template it mirrors, cover 14. The two extra roles in security defaults are Authentication Policy Administrator and Identity Governance Administrator.
If a small tenant is on security defaults, think hard before switching it off: the moment you do, you lose protections that you then have to rebuild in Conditional Access yourself.
Sponsored by:
ENow Software Introduces New Entra ID App Onboarding Experience
As user requests for SaaS and AI applications increase, Entra ID and M365 teams face a growing volume of security reviews, added hours of manual research, and bottlenecks.
New! ENow App Governance Accelerator 4.0 introduces App Onboarding, helping teams:
* Accelerate app approvals with configurable, multistage workflows.
* Evaluate security risks more efficiently with integrated Microsoft Defender for Cloud Apps risk scores.
* Reduce manual work with centralized requests, reviews, and approvals.
* Improve transparency with a self-service portal for requesters to track status and decisions.
* Control app sprawl with an Internal App Catalog of approved applications.
Go beyond Microsoft’s consent and approval capabilities with customizable, structured application governance, from the initial request through ongoing oversight.
Faster Approvals. Less Admin Work. Better Security Posture.
Learn More About ENow App Governance Accelerator 4.0
See It In Action: Request a Demo
Decide which roles are privileged yourself
“We require MFA on privileged roles” is easy to say in an audit. An assessment asks a harder question: privileged by whose definition? Brandon’s own list is about 36 roles, grouped into tier 0 and tier 1, the same tiering model Active Directory admins used 20 years ago.
Don’t lean on Microsoft’s mandatory MFA either. It covers the Azure portal, the Microsoft Entra admin center, the Intune admin center and the Microsoft 365 admin center, plus create, update and delete operations from Azure CLI, Azure PowerShell, the Azure mobile app and IaC tools. Microsoft Graph APIs are generally not in scope, so in some cases a single-factor sign-in can still reach Graph. Your Conditional Access still has to cover every app and every role you consider privileged.
Every platform is not all platforms
Conditions inside one policy combine with AND. A policy that requires MFA when the user is risky, the sign-in is risky and the location is outside the United States only fires when all three are true at once, so it almost never fires. Put conditions that should act on their own into separate policies.
The device platforms condition has the same trap. Ticking Android, iOS, Windows, macOS and Linux is not the same as “any device”. The platform comes from the user agent string, which isn’t verified and is easy to change, so a sign-in that claims an unknown platform matches none of your platform policies and walks past all of them. Microsoft’s recommended fix is a separate block policy: include Any device, exclude the platforms you support, and set the grant to Block access. Brandon covers how the spoofing works in his Petri article (linked below).
Watch this episode…
Conditional Access has no allow rule
Customers often ask for a policy that will “allow finance access to the finance app”. Conditional Access has no allow rule. A policy is an if-then statement: if the users, target resources and conditions match, then require MFA, a compliant device or another control, or block. Anything the policy doesn’t match passes through untouched.
So every time you narrow the users, the apps or the conditions to describe who should get in, you also shrink what the policy protects. Scope policies broadly and carve out exclusions on purpose.
Testing: ask what a policy doesn’t do
Testing usually covers the happy path: the right user opens the right app and gets an MFA prompt. The gaps are in the paths nobody tried: the user who isn’t in the group, the unmanaged device, the other network. Two locations, managed and unmanaged devices, a few apps and a few user types already make dozens of test cases, and every new condition (insider risk from Microsoft Purview, for example) multiplies them again.
The useful question isn’t “what does this policy do?” but “what doesn’t it do, and does something else cover that?” When you add a role or group to one policy, check whether it should come out of another.
Tools help:
* What If tool: simulate a sign-in for a user, app, device platform and location, and see which policies apply.
* Conditional Access Optimization Agent: Microsoft Security Copilot reviews your policies and suggests new policies (created in report-only mode) and changes for you to approve. It needs Microsoft Entra ID P1 and security compute units.
* AI with sanitized data: as a consultant, Brandon often can’t run tools inside a customer’s tenant. He exports the policies as JSON, removes tenant names, group names and IDs, and asks an AI model to explain a specific coverage question. Challenge the answers and verify them; don’t take them on trust.
User actions and device code flow
Two gaps Brandon still finds often:
* User actions. Conditional Access can target Register security information and Register or join devices. Without a policy on these, registering an MFA method or a device is protected only by whatever the sign-in itself required.
* Device code flow. Microsoft deploys a managed policy that blocks it in some tenants, but Brandon has seen it deployed only about three times. Check whether you need it: filter the sign-in logs by authentication protocol for device code and see who uses it. Legitimate users are usually input-constrained devices such as Teams phones and Teams Rooms. At one customer, the single device code sign-in turned out to be their own penetration test. Then block it with an authentication flows policy and exclude only what genuinely needs it.
Trusted locations: the exception that switches MFA off
A common policy reads: require strong authentication for all users, all apps, everywhere, except trusted locations. It was best practice once. In effect it means single-factor sign-in at the office, and it often survives after the rest of the policy has been modernized.
On Microsoft Entra joined and hybrid joined Windows devices you don’t need the exception for single sign-on. The primary refresh token (PRT) provides SSO to apps and carries the MFA claim. The exception only lets users skip strong authentication.
Flip how you use locations. Instead of using them to relax MFA, use them to lock down the accounts that can’t do MFA, such as service accounts, shared accounts and kiosk accounts, so they only work from specific IP ranges and devices.
While you’re there:
* MFA trusted IPs in the legacy MFA service settings are IPv4-only and not recommended. The “All trusted networks and locations” option in Conditional Access includes them. The checkbox to skip MFA for federated users on your intranet belongs to the same legacy settings.
* Continuous access evaluation checks IP-based named locations at the resource. Include both IPv4 and IPv6 ranges, or IP mismatches will cause unexpected behaviour.
* Check your ranges. Few admins still calculate subnets by hand. AI can help, as long as you check the answer: ask whether a specific IP is inside a specific range rather than accepting “it’s a /8”.
* Compliant network. With Global Secure Access and the Microsoft traffic profile, the compliant network check in Conditional Access is included with Microsoft Entra ID P1. It follows the device rather than the building, which suits people who move around with their laptops.
Apps: the back door
There are no unpatched Entra servers for an attacker to exploit, so the ways in are user sign-in and apps. Once an app is in the tenant, consented, holding permissions and a client secret, it lives there until someone actively looks at it. A single leaked client secret can be all an attacker needs, and none of the controls on user sign-in apply to it. Prefer certificates, and better still managed identities or workload identity federation, over client secrets.
Redirect URIs and dangling domains
A redirect URI (reply URL) is where Microsoft Entra sends the token after a user signs in. If an attacker controls that URL, they get the token from a completely legitimate Microsoft sign-in, usually started by a phishing link. Watch for three kinds:
* Old redirect URIs left behind after an app moved.
* Wildcards, which Microsoft’s guidance says not to use.
* Reclaimed domains: names you let go that someone else can register.
The classic case is azurewebsites.net. Developers used App Service default hostnames because they came with TLS and needed no DNS or PKI tickets. When a web app was deleted, anyone could create a new app with the same name and receive the tokens for any redirect URI still pointing at it. The redirect URIs of a multitenant app are visible to every tenant that uses it, so attackers can build lists and look for dangling names. Azure App Service now creates new apps with secure unique default hostnames (-..azurewebsites.net) by default in the Azure portal, so a deleted name can’t simply be re-registered by someone else.
A stale domain doesn’t mean a dead app: an app with several redirect URIs can still be in daily use while one of them points at a name nobody owns. It happens to everyone. A Zero Trust Assessment check once flagged a reply URL on Microsoft’s own Microsoft Graph PowerShell app that pointed to an invalid domain, and Microsoft removed it. The odds of any one tenant being hit are small, but it’s a cheap thing to check: own the domain behind every redirect URI, remove the ones you don’t use, and don’t use wildcards.
Homegrown apps can leak tokens too. If an app stores tokens in browser local storage and has a cross-site scripting bug, an attacker can read the token and send it to their own server. Anyone who uses that app with consented permissions can then be impersonated.
The checkbox: consent on behalf of your organization
Application permissions look dangerous at a glance, because the app acts as itself. Delegated permissions are quieter: the app acts as the signed-in user, with whatever that user can do.
When an admin is asked to consent, the prompt has a Consent on behalf of your organization checkbox, unticked by default. It looks like the helpful thing to tick. Ticked, it creates a tenant-wide grant (consentType: AllPrincipals) for every user. If the app has an elevated delegated permission such as Directory.ReadWrite.All and a Global Administrator later signs in to it, the app can act with that admin’s rights across the directory.
Two habits close most of the gap:
* Leave the checkbox unticked. Consent for yourself unless the whole organization really needs the app.
* If you do consent for everyone, set Assignment required? to Yes on the enterprise app and assign only the users and groups who should use it. Note that Global Administrators aren’t blocked by the assignment requirement.
Where are my privileged apps?
There’s no single page in the portal that answers “where are my privileged applications?” In the GUI you click into each app, open API permissions and review it, one app at a time. The answers you need are spread out:
* Microsoft Entra admin center: the Conditional Access Coverage tab (apps with and without Conditional Access coverage), the Conditional Access gap analyzer workbook, and Microsoft Entra recommendations such as “Remove unused applications” and “Remove unused credentials from applications”.
* Microsoft Defender for Cloud Apps: app governance lists highly privileged, overprivileged and unused apps, if you’re licensed for it. Many organizations are licensed and don’t know.
* Maester: pulls these checks into one report you can run on a schedule.
* Microsoft Secure Score: a good place to start, not a place to stop.
Write it up
If you’ve hit a problem in your tenant, someone else has hit it too. Write it up, blog it or submit a talk about it. Even if the topic has been covered a hundred times, your angle may be the one that makes it click for somebody.
About Brandon Colley
Brandon Colley is a Senior Security Consultant at TrustedSec and a Microsoft Security MVP, with about 20 years of experience administering and securing Active Directory and Microsoft cloud environments. He started on the help desk and in systems administration in higher education, then moved into security at Trimarc, where he learned Active Directory security from Sean Metcalf and ran Trimarc’s Microsoft cloud security assessment. At TrustedSec he runs cloud and on-premises assessments and remediation, researches and writes about Conditional Access and Entra application security, and speaks at conferences across the US.
LinkedIn - https://www.linkedin.com/in/techbrandon/
Related Links
From the conversation:
* How Unsupported Devices Can Bypass Microsoft Entra Conditional Access Policies, by Brandon Colley on Petri (mentioned at 12:57) - https://petri.com/bypass-entra-conditional-access-policies/
* Sean Metcalf on Entra.Chat: Stop Leaving the Door Open, the Entra ID hardening checklist (mentioned at 04:14) - https://entra.news/p/stop-leaving-the-door-open-the-entra
* Maester (mentioned at 09:53) - https://maester.dev
* Zero Trust Assessment (mentioned at 31:35) - https://learn.microsoft.com/en-us/security/zero-trust/assessment/overview
Conditional Access:
* Security defaults in Microsoft Entra ID (mentioned at 08:24) - https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults
* Microsoft-managed Conditional Access policies (mentioned at 08:35) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies
* Require MFA for administrators (Conditional Access template) (mentioned at 08:35) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-old-require-mfa-admin
* Mandatory multifactor authentication for Azure and admin portals (mentioned at 10:05) - https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication
* Build a Conditional Access policy (mentioned at 11:32) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policies
* Conditional Access conditions: device platforms and insider risk (mentioned at 11:57) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-conditions
* Block access for unknown or unsupported device platform (mentioned at 11:57) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-unknown-unsupported
* What If tool (mentioned at 17:01) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/what-if-tool
* Conditional Access Optimization Agent (mentioned at 17:32) - https://learn.microsoft.com/en-us/entra/security-copilot/conditional-access-agent-optimization
* Target resources, including user actions (mentioned at 17:54) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps
* Authentication flows and device code flow (mentioned at 18:06) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows
* Block authentication flows with Conditional Access (mentioned at 18:19) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows
* Network assignment and trusted named locations (mentioned at 20:34) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-assignment-network
* Primary refresh token (mentioned at 21:53) - https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token
* MFA trusted IPs (legacy MFA service settings) (mentioned at 23:05) - https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-mfasettings
* Enable the compliant network check with Conditional Access (mentioned at 23:18) - https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-compliant-network
* Continuous access evaluation (mentioned at 23:33) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
Apps and consent:
* Security best practices for application properties: redirect URIs (mentioned at 27:21) - https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration
* Redirect URI (reply URL) best practices and limitations - https://learn.microsoft.com/en-us/entra/identity-platform/reply-url
* Microsoft identity platform integration checklist: credentials - https://learn.microsoft.com/en-us/entra/identity-platform/identity-platform-integration-checklist
* Prevent subdomain takeovers (mentioned at 28:49) - https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover
* App Service secure unique default hostnames (mentioned at 29:56) - https://learn.microsoft.com/en-us/azure/app-service/reference-dangling-subdomain-prevention
* Understanding the application consent experience (mentioned at 32:51) - https://learn.microsoft.com/en-us/entra/identity-platform/application-consent-experience
* Grant tenant-wide admin consent to an application - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent
* Restrict an app to a set of users (Assignment required) (mentioned at 33:55) - https://learn.microsoft.com/en-us/entra/identity-platform/howto-restrict-your-app-to-a-set-of-users
* App governance visibility and insights in Defender for Cloud Apps (mentioned at 35:00) - https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-visibility-insights-overview
* What is Conditional Access? (the Coverage tab) (mentioned at 35:28) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
* Conditional Access gap analyzer workbook (mentioned at 35:28) - https://learn.microsoft.com/en-us/entra/identity/monitoring-health/workbook-conditional-access-gap-analyzer
* What are Microsoft Entra recommendations? (mentioned at 35:33) - https://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-recommendations
* Microsoft Secure Score (mentioned at 36:25) - https://learn.microsoft.com/en-us/defender-xdr/microsoft-secure-score
Related Entra.Chat Episodes
* The Ultimate Microsoft Entra Global Secure Access Migration Guide, with the device platforms tip (mentioned at 11:14) - https://entra.news/p/the-ultimate-microsoft-entra-global
* Stop the Bleeding: Cleaning Up Apps, Secrets and Consent in Microsoft Entra (mentioned at 25:47) - https://entra.news/p/stop-the-bleeding-cleaning-up-apps
* Your AI Coding Agent Is Creating Secrets You Don’t Know About (mentioned at 25:47) - https://entra.news/p/your-ai-coding-agent-is-creating
Chapters
00:00 Cold open
01:03 Intro
01:22 Meet Brandon Colley
06:50 Security defaults vs the managed policy
09:35 Which admin roles really matter?
11:01 Every platform is not all platforms
13:32 Conditional Access has no allow rule
14:11 The testing explosion
16:06 Using AI to untangle your policies
17:47 User actions and device code flow
19:22 Sponsor: ENow App Governance Accelerator
20:24 Trusted locations: the MFA loophole
25:19 Apps: the back door
27:17 Redirect URIs and domain takeover
32:11 Consent for everyone
34:18 Where are my privileged apps?
36:38 Write it up
Podcast Apps
Entra.Chat - https://entra.chat
Apple Podcast - https://entra.chat/apple
YouTube - https://entra.chat/youtube
Spotify - https://entra.chat/spotify
Overcast - https://entra.chat/overcast
Pocketcast - https://entra.chat/pocketcast
Others - https://entra.chat/rss
Merill’s socials
YouTube - youtube.com/@merillx
LinkedIn - linkedin.com/in/merill
Twitter - twitter.com/merill
TikTok - tiktok.com/@merillf
Bluesky - bsky.app/profile/merill.net
Mastodon - infosec.exchange/@merill
Threads - threads.net/@merillf
GitHub - github.com/merill


Get full access to Entra.News - Your weekly dose of Microsoft Entra at entra.news/subscribe

Most tenants have the same problem: hundreds of app registrations and service principals, client secrets that were set to expire in a hundred years, permission grants nobody remembers approving, and test tenants that were never cleaned up. It’s tempting to start fixing the scariest app on the list. Jeff Sakowicz argues for a different order: stop the problem from growing first, then remove the debt that gives you the most risk reduction for the least disruption.
Jeff isn’t describing someone else’s product. He has spent most of his 14 years at Microsoft as a product leader on the Entra application platform, shaping the application and service principal model and the OAuth permissions and consent model that every Entra tenant runs on today. Publisher verification and risk-based step-up consent came out of that work, and he now leads part of the team building the platform behind Microsoft Entra Agent ID. Inside Microsoft, he’s the person teams call when an app incident needs untangling. This is his playbook for securing non-human identities, from client secret burndown and unused apps to consent phishing and the protections Microsoft runs in every tenant by default.

Prevention starts with policy
The best medicine is prevention. Before you clean anything up, go through the policy controls you already have and set them to block insecure configuration that doesn’t fit your organization’s risk tolerance. This is a balance, not a switch. “If you want the most secure system in the world, unplug the server, bury it underground. Your job is done.” Lock things down too hard and developers and end users will find other ways to get work done, especially now that they have agents to help them. Shadow IT is almost always less secure than what you stopped. So whenever a control blocks self-service, make sure people know what to do next and how to get unblocked quickly.
Treat high-value apps as production infrastructure
Microsoft runs customer-facing apps in tenants separate from its corporate tenant. Tenant-level isolation is a useful form of segmentation, and some large organizations do the same for their production assets. But a second tenant brings its own operational overhead, and a tenant that falls into chaos can leave you worse off than before.
Whatever you decide, treat your multitenant apps and high-value line-of-business apps as production infrastructure, the same way you would protect a database or a high-value Azure subscription. A good middle ground is to keep a close eye on the owners and sponsors of your high-value apps and agent identities. They are the people who can change those identities’ authentication configuration, so their accounts need good hygiene.
The easier win is test, demo and staging. If they still live in your productivity or production tenant, move them out. Midnight Blizzard showed how small dominoes lead to big consequences: Microsoft’s own write-up describes a password spray against a legacy, non-production test tenant account, followed by a legacy test OAuth application that had elevated access to the corporate environment.

Sponsored by
Many of the app and consent problems in this episode are exactly what Maester checks for: it runs security tests against your Microsoft Entra and Microsoft 365 configuration and tells you what passed and what failed.
Maester Cloud turns those results into a workflow your team can run every day:
* Assign an owner to each finding and link it to a ticket, instead of tracking remediation in a spreadsheet.
* See what got fixed since the last run, and record accepted risks.
* Catch drift with daily history and alerts when a setting changes.
* Every tenant in one place, without switching sign-ins.

Subscribe with your favorite podcast player or watch on YouTube
Map your surface area, then think in three dimensions
Before buying a new inventory tool, use the one you already have. If your organization already tracks production assets or other identities, bring your non-human identities into that system instead of running a parallel process. Then answer three questions: how many of these do I have, what categories of identity are in the portfolio, and what are the big categories of risk?
Jeff looks at risk in three dimensions:
* Active threats. Priority zero. Hand them to the SOC immediately.
* Posture. Surface area from misconfiguration, or configuration that was state of the art five years ago, such as the implicit flow for a single-page app. Weak credentials, insecure redirect URIs, unused identities and legacy protocols all live here.
* Blast radius. How much privilege each identity has, whether it’s used or not.
Most organizations end up with a huge list of high-privilege apps and posture issues. You will never get every risk to zero at that scale, so the job is to prioritise by risk and by return on effort.
Burn down secrets: stop the bleeding first
Say you’ve read the Solorigate reports and want to get client secrets off your non-human identities. Step one is to stop the bleeding: create an app management policy that blocks new password credentials from being added. App management policies can take an enforcement date, so only apps created after that date are affected and your hundreds of existing apps keep working while you fix them. There is no equivalent for user authentication methods.
Before you switch it on, find out how disruptive it will be. One new app a month that uses a password credential is easy to absorb. A hundred a day could grind the organization to a halt. Have the guidance and the exception process ready, and move the enforcement date if you need to.
Once the problem has stopped growing, turn to the debt. Split it into categories and start with the two ends of the spectrum:
* The most privileged. Apps with existing passwords that have app-only access to read all mailboxes or read and write all user profiles go to the top of the list. Move them to a stronger credential and check whether they need that access at all.
* The wholly unused. More on this below.
The end goal is system-managed credentials, using a managed identity or workload identity federation with a federated identity credential (FIC). You can argue a certificate’s private key is harder to leak than a secret, but as Jeff says, “a bad copy-paste is a bad copy-paste.” System-managed credentials also remove a big source of toil for developers, which helps when you need people to move.
Why mail is the flag
Mail permissions can look less frightening than broad directory permissions, but for many attacks mail is the goal. “Mail’s often the flag that the attacker’s trying to capture.” Other access is often just a way to move laterally or elevate privilege. Mail, Teams chats and files can be the end goal, and that is what most historical consent phishing attacks went after. A mailbox is also a good lateral movement tool: it can hold credentials and bank details, and it gives an attacker what they need to craft a convincing social engineering attack against everyone the victim emails or chats with every day.
Lost secrets make this worse. A secret that is valid for years, used by apps nobody can name, gives an attacker a way in without adding a new credential, so there’s no new event for you to trace.
Unused identities: the highest return on effort
A wholly unused identity is the highest-ROI bucket. “If you get rid of an unused identity, you might be knocking an item off of seven lists.” In one move you can remove a weak password, an insecure redirect URI, overprivileged access and some legacy protocol usage. Do your due diligence first, because some apps only run once a year at tax season. But removing something that is truly unused doesn’t disrupt anyone, and it can be done as a central action by a single team without engaging every app owner. That high-leverage central action is what Microsoft leaned into for its Secure Future Initiative work.
Then look at low-usage identities. They hide in plain sight: an identity with an automated runner that wakes up every day to run a test suite won’t show up as unused, and may not be privileged enough to make your red list. Look closely and you find the same two token requests every day for months, with no person or agent relying on them. Microsoft Entra recommendations already flag unused applications and unused credentials.
Consent phishing and your consent policy
A small set of controls drastically reduces the chance of a compromise through consent phishing, and the first is a consent policy. Microsoft has revised the defaults several times over the last few years and they are now in a good state, but check yours and tune it for your organization.
Older tenants deserve a second look in both directions. Many organizations turned user consent fully off around 2019, when consent phishing surged and the setting was just on or off. The modern consent policy framework now offers far more granular options, so you can enable the self-service your business needs without opening a hole. Note that changing your consent settings only affects future consent; existing grants stay in place.
The protections you don’t see
Publisher verification is more than a blue checkmark. Microsoft uses it as a signal in several places. By default, multitenant apps registered after November 8, 2020 that don’t have a verified publisher can’t get user consent from other tenants unless they only ask for basic sign-in and profile permissions.
Risk-based step-up consent is another. It’s on by default in every tenant, and when a user consent request looks risky it requires an admin instead, even when the user would normally be allowed to consent. Microsoft built it this way because once a user takes the lure and lands on a consent screen, “the click-through rate on the actual consent prompt was very, very high.” The best defence is to stop them getting there. Microsoft also detects and takes down campaigns that use malicious apps.
Before you grant consent: a checklist
Step-up consent sends more requests to admins, and admins are confused by consent screens too. A short list of scary permissions can look safer than a long list of granular ones. Jeff’s checklist:
* Sanity check. What is this, why am I being asked, and does it make sense for the business? Many attacks are illogical when you stop to think: you weren’t actually trying to redeem an Uber gift card.
* Check the publisher. From outside the organization, does it have a verified publisher? From inside, who built it, and do you trust them to maintain a well-secured identity?
* Read the permissions, not the length. Directory.ReadWrite.All can cover what 15 or 20 granular permissions do. A longer list isn’t necessarily worse.
* Weigh business value against risk. Access the app doesn’t need, or access whose value doesn’t justify the risk, adds surface area and blast radius. That is the harder conversation, and the important one.
Three places to start
Find out which capabilities your licences give you, because some useful tools are in Microsoft Defender and not every organization has them. Then start on the policy side: stop the problem from getting bigger, turn on right away anything that won’t disrupt existing productivity, and put the disruptive controls in your plan. In parallel, use Microsoft Entra recommendations, Defender, ID Protection and ID Governance to work through the existing debt, starting with the highest-risk and highest-ROI items you can fix with a small set of central actions.
If you want SKU-light places to start, Jeff names three: consent policies, app management policies and Microsoft Entra recommendations (some recommendations have licence requirements).
The same lessons apply to agents
Agent identities follow the same pattern. Microsoft built protections into the core Agent ID model to reduce or remove some of these risks, but some development-friendly options are fine in development and risky in production. Privilege reduction and the rest of this playbook apply to agents just as they do to service principals, so get ahead of your agent portfolio now and manage your whole non-human identity fleet together.
About Jeff Sakowicz
Jeff Sakowicz is a Principal PM Manager on Microsoft Entra, where he leads part of the application platform team: the control plane for non-human identities, including the core data model, APIs and experiences for apps, service principals and Microsoft Entra Agent ID, and how they are configured securely.
In 14 years at Microsoft he has helped build much of the identity platform admins use every day. He started in identity support, moved into program management on the core directory team (including a stint as PM for DirSync), worked on Azure AD Graph and Microsoft Graph, and then spent most of his career leading product work on the application and service principal model and the OAuth permissions and consent model, including publisher verification and risk-based step-up consent.
LinkedIn - https://www.linkedin.com/in/jeffsakowicz/
Related Links
Jeff’s recommended reading (mentioned at 46:03):
* Protect against consent phishing - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing
* Configure how users consent to applications - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?pivots=portal
* Configure app management policies (restrictions on how applications can be configured) - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-app-management-policies?tabs=portal
* Security best practices for application properties - https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration
* What are Microsoft Entra recommendations? - https://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-recommendations
* Overview of Microsoft Defender for Cloud Apps (mentioned at 47:19) - https://learn.microsoft.com/en-us/defender-cloud-apps/what-is-defender-for-cloud-apps
* Non-human identities in Microsoft Defender (Preview; excludes managed identities and Microsoft first-party apps) - https://learn.microsoft.com/en-us/defender-xdr/investigate-non-human-identities
* Incident response playbooks - https://learn.microsoft.com/en-us/security/operations/incident-response-playbooks
More from the episode:
* Recommendation to remove unused applications (mentioned at 45:29) - https://learn.microsoft.com/en-us/entra/identity/monitoring-health/recommendation-remove-unused-apps
* Recommendation to remove unused credentials from applications (mentioned at 45:29) - https://learn.microsoft.com/en-us/entra/identity/monitoring-health/recommendation-remove-unused-credential-from-apps
* What are workload identities? (mentioned at 28:30) - https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview
* Workload identity federation (mentioned at 28:30) - https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
* Publisher verification (mentioned at 33:58) - https://learn.microsoft.com/en-us/entra/identity-platform/publisher-verification-overview
* Configure risk-based step-up consent (mentioned at 35:36) - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-risk-based-step-up-consent
* Overview of permissions and consent in the Microsoft identity platform (mentioned at 41:34) - https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview
* Configure the admin consent workflow (does not clean up existing grants) - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow
* Review permissions granted to enterprise applications - https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-application-permissions
* Get started with app governance in Defender for Cloud Apps (mentioned at 47:19) - https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-trial-user-guide
* Microsoft actions following attack by nation state actor Midnight Blizzard (mentioned at 42:59) - https://www.microsoft.com/en-us/msrc/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard
* Midnight Blizzard: guidance for responders on nation-state attack (mentioned at 42:59) - https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/
* Secure Future Initiative: September 2024 progress update (mentioned at 26:11) - https://www.microsoft.com/en-us/security/blog/2024/09/23/securing-our-future-september-2024-progress-update-on-microsofts-secure-future-initiative-sfi/
* Best practices for Microsoft Entra Agent ID (mentioned at 49:03) - https://learn.microsoft.com/en-us/entra/agent-id/best-practices-agent-id
Related Entra.Chat Episodes
* The Ultimate Guide to App Consent in Microsoft Entra (mentioned at 29:58) - https://entra.news/p/the-ultimate-guide-to-app-consent
* Inside Microsoft’s Entra Tenant: The Internal App Governance Playbook - https://entra.news/p/inside-microsofts-entra-tenant-the
* The Hidden Risks of Non-Human Identities in Your Tenant - https://entra.news/p/the-hidden-risks-of-non-human-identities
Chapters
01:05 Intro
01:23 Meet Jeff Sakowicz
05:04 Prevention starts with policy
07:31 Should your apps get their own tenant?
11:50 Where do you even start?
16:05 Burn down secrets: stop the bleeding
19:47 Why mailboxes are the prize
23:18 Unused identities: the highest ROI
26:33 What actually gets orgs moving
29:16 Consent phishing and your consent policy
33:23 The protections you don’t see
38:13 Before you grant consent: a checklist
43:00 Midnight Blizzard and forgotten tenants
44:08 Low-usage identities in plain sight
45:28 Three places to start
49:03 Agents are next
Podcast Apps
Entra.Chat - https://entra.chat
Apple Podcast - https://entra.chat/apple
YouTube - https://entra.chat/youtube
Spotify - https://entra.chat/spotify
Overcast - https://entra.chat/overcast
Pocketcast - https://entra.chat/pocketcast
Others - https://entra.chat/rss
Merill’s socials
YouTube - youtube.com/@merillx
LinkedIn - linkedin.com/in/merill
Twitter - twitter.com/merill
TikTok - tiktok.com/@merillf
Bluesky - bsky.app/profile/merill.net
Mastodon - infosec.exchange/@merill
Threads - threads.net/@merillf
GitHub - github.com/merill


Get full access to Entra.News - Your weekly dose of Microsoft Entra at entra.news/subscribe

A phished and stolen refresh token is one of the most useful things an attacker can take from your tenant. It is a long-term artifact, which is why so many phishing attempts go after it. Alex Pavlovsky’s answer to that attack is a feature every Entra ID P1 tenant already owns.
Compliant network is part of Global Secure Access, and, like source IP restoration, it comes with Entra ID P1. Put the GSA client on your devices, add one Conditional Access policy that blocks access from anywhere outside the All Compliant Network locations named location, and a stolen refresh token or PRT cookie no longer works from the attacker’s own machine. As Alex puts it, the token itself does not become bound, but your use of it is gated by being on your organization’s compliant network.
Merill is joined by two former colleagues who are Microsoft Entra PMs: Alexander (Alex) Pavlovsky from the Global Secure Access feature team, and Marilee Turscak, who works on helping customers adopt AI safely. They explain why Microsoft built networking into identity, walk through the compliant network policy and a BYOD sign-in with no client installed, and demo a network policy that stops an agent from deleting a file its user is allowed to delete.
Why a stolen token stops working
For phishing itself, Alex is clear that the main line of defence is still stronger credentials that do not involve passwords. Compliant network helps with what comes after: the newer attack patterns where refresh tokens are stolen and replayed.
If your tenant-wide policy says you can only authenticate from a compliant network, you can also only replay refresh tokens from a compliant network. PRTs become unusable unless they are used from a device that has GSA, which means your organization’s device. Alex says the same applies to ROADtools-style attacks with PRT cookies: none of that works with compliant network in place. The signal is also tenant-specific. A GSA device in tenant B satisfies compliant network in tenant B and nowhere else.
In the demo, Alex builds the policy in a few clicks: all users, all resources (so the primary refresh token, Entra ID itself and Microsoft Graph are covered), any network except compliant network locations, then block. Start it in report-only mode, watch who is not coming through compliant network, pilot with a smaller group and expand. You do not need the advanced GSA licences for this, but you do need the GSA client on your devices or a remote network sending the traffic.
And exclude your break glass accounts. Alex has taken many panicked customer calls from admins who forgot, and Marilee locked herself out of a test tenant this way recently.
One engine for identity and network
When Merill joined Microsoft, he couldn’t see why networking belonged to the identity team. Alex explains the reasoning. When identity picks up a signal that a user, session or token is at risk, the network has to hear about it quickly, and passing those signals between separate systems through traditional APIs is too slow at this scale. So Microsoft made the identity engine and the network engine one engine.
That design shows up in source IP restoration. Behind a typical proxy or security service edge, every user looks like they signed in from the provider’s shared IP range. GSA sends the user’s original source IP to Entra securely, so sign-in logs are accurate, Conditional Access can evaluate the user’s own IP, and Identity Protection’s location and impossible travel detections work again. It is also why compliant network works at all: the GSA edge shares a security engine with Entra ID, so it can tell Entra that this is a legitimate GSA device from a specific tenant, and Entra can trust that signal.
The network can tell agents from users
“Agents are super deterministic. They are very resourceful. They do not give up.” Alex also argues that saying no to agents means falling behind your competitors, so the question becomes how to protect their use.
GSA can detect when network access comes from an agent, and its policy rules can match on the HTTP method, the destination and whether a user or an agent is acting. Marilee’s baseline recommendation is to block sensitive actions by agents. In her demo, the Zava helper agent tries to remove a document from Dropbox and gets an “agent is not authorized” error, because a policy called “block agents from destructive actions” blocks the DELETE method for agents only. The user checkbox is left clear, so the person can still delete the file themselves. The logs show the same attribution, which Alex says is valuable even before you apply any policy.
Alex also describes Copilot Studio agents running through GSA with no client anywhere. A Copilot Studio admin checks one box to enable the GSA integration, and with Internet Access and a policy in place, that agent traffic flows through GSA and your policies apply.
BYOD without the client
Marilee shows a user on a personal device with no GSA client. When she signs in, she is prompted to switch to her work browser profile, and from then on Explicit Forward Proxy sends that profile’s traffic through GSA. When she tries to open Facebook, she is blocked inside the work profile and nowhere else on her device. Alex sees the managed Edge profile becoming a sandbox with secure network access and Purview DLP, which could reduce the need for remote browser isolation. The full client still gets the most features, including agent detection, and remote networks are a third way to send traffic through GSA.
Universal CAE now acts on device state
Continuous access evaluation used to depend on applications that understood it, which mostly meant SharePoint, Teams and Exchange. Send an app’s traffic through GSA and it becomes CAE-aware too, including private apps. If an admin is on an SSH session over GSA and Entra flags their identity, Alex says the session is dead within about two to five minutes, even if their token is good for another 90 minutes.
The week before recording, Microsoft added device state support. If Intune or a third-party MDM marks a device non-compliant in Entra ID, GSA asks the user to bring it back into compliance or lose network connectivity. User risk changes and device deletion or disablement also trigger it now. If you already run GSA, you get this without changing anything, which is Merill’s favourite kind of feature.
If you have Entra ID P1 and have never deployed the GSA client, compliant network is the place to start.

About Alexander Pavlovsky
Alexander Pavlovsky is a Product Manager on the Microsoft Entra Global Secure Access feature team. He has been at Microsoft for 22 years. He started in Microsoft Consulting, installing domain controllers and Exchange servers for customers from CDs, then moved to the identity product team as a customer-facing PM in the Entra GTP (Get To Production) team, later CXE (Customer Experience), helping organizations adopt Azure AD.
LinkedIn - https://linkedin.com/in/alexpav
About Marilee Turscak
Marilee Turscak is a Product Manager on the Microsoft Security team focusing on Microsoft Entra. For the past two years she has focused on getting customers deployed across the Microsoft Entra Suite, and she now works on helping customers adopt AI safely and securely.
LinkedIn - https://linkedin.com/in/marilee-turscak
Related Links
* What is Global Secure Access? - overview and the licensing table for each feature (mentioned at 10:08) - https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access
* Source IP restoration (mentioned at 15:07) - https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-source-ip-restoration
* Universal Conditional Access (mentioned at 15:26) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-universal-conditional-access
* Universal Tenant Restrictions (mentioned at 15:26) - https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-universal-tenant-restrictions
* Compliant network check with Conditional Access (mentioned at 18:24) - https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-compliant-network
* ROADtools - the Azure AD and Entra ID exploration framework behind many PRT cookie attacks (mentioned at 21:19) - https://github.com/dirkjanm/ROADtools
* BYOD with Global Secure Access (mentioned at 23:30) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-bring-your-own-device
* Explicit Forward Proxy overview (mentioned at 24:31) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-explicit-forward-proxy
* Configure Explicit Forward Proxy for Microsoft Edge with Intune (mentioned at 25:06) - https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-explicit-forward-proxy-intune-policy
* WebMCP (mentioned at 27:05) - https://github.com/webmachinelearning/webmcp
* Remote network connectivity (mentioned at 27:54) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-remote-network-connectivity
* Web filtering, including rules that match on user or agent and HTTP method (mentioned at 29:43) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-web-filtering
* AI agent discovery (mentioned at 29:43) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-ai-agent-discovery
* Secure Web and AI Gateway for Copilot Studio agents (mentioned at 34:13) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-secure-web-ai-gateway-agents
* Set up Global Secure Access for Copilot Studio agents (mentioned at 34:13) - https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-secure-web-ai-gateway-agents
* Tutorial: require a compliant network for Microsoft traffic (mentioned at 39:22) - https://learn.microsoft.com/en-us/entra/global-secure-access/tutorial-microsoft-traffic-compliant-network
* Manage emergency access (break glass) accounts (mentioned at 41:01) - https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
* Conditional Access report-only mode (mentioned at 42:52) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only
* Universal Continuous Access Evaluation (mentioned at 45:12) - https://learn.microsoft.com/en-us/entra/global-secure-access/concept-universal-continuous-access-evaluation
* Continuous access evaluation in Microsoft Entra ID (mentioned at 45:12) - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
Related Entra.Chat Episodes
* Identity-Centric Network Security: Entra Global Secure Access Architecture & Benefits - https://entra.news/p/identity-centric-network-security
* Global Secure Access Explained: Real-World Rollouts, Mistakes, and Best Practices - https://entra.news/p/global-secure-access-explained-real
* The Ultimate Microsoft Entra Global Secure Access Migration Guide - https://entra.news/p/the-ultimate-microsoft-entra-global
Chapters
00:00 Cold open01:14 Intro01:32 Meet Alex and Marilee05:18 Why networking became part of identity10:08 How Global Secure Access works15:07 Source IP restoration18:24 Compliant network comes with Entra ID P119:51 Compliant network vs stolen tokens21:47 How compliant network actually works23:30 BYOD without the client29:43 Telling agents apart from users31:02 Baseline: block risky agent actions34:13 Copilot Studio agents through GSA37:20 Identity and network teams must converge39:22 Demo: require a compliant network43:45 What happens to a stolen token45:12 Universal continuous access evaluation49:35 Wrap-up
Podcast Apps
Entra.Chat - https://entra.chat
Apple Podcast - https://entra.chat/apple
YouTube - https://entra.chat/youtube
Spotify - https://entra.chat/spotify
Overcast - https://entra.chat/overcast
Pocketcast - https://entra.chat/pocketcast
Others - https://entra.chat/rss
Merill’s socials
YouTube - youtube.com/@merillx
LinkedIn - linkedin.com/in/merill
Twitter - twitter.com/merill
TikTok - tiktok.com/@merillf
Bluesky - bsky.app/profile/merill.net
Mastodon - infosec.exchange/@merill
Threads - threads.net/@merillf
GitHub - github.com/merill


Get full access to Entra.News - Your weekly dose of Microsoft Entra at entra.news/subscribe

Ask a coding agent to build something that talks to another service and watch what it does. It creates a client secret. Then another one. As Arturo Lucatero puts it, next thing you know you have ten secrets that were created without you knowing about it. At the speed AI is moving, he thinks we could be cleaning up a few million new secrets within six months.
That would undo a lot of hard work. Under Microsoft’s Secure Future Initiative, Microsoft spent years removing secrets from its own estate and helping customers do the same with managed identities and workload identity federation. The agent era is the window to make secretless the default before the habit sets in.
Arturo is a Principal Product Manager on Microsoft Entra Agent ID, and he helped launch Managed Service Identity, the feature we now call Managed Identities for Azure resources. In this episode he and Merill trace the whole path: why secrets break, how managed identity takes them away inside Azure, how workload identity federation extends that to AWS, GCP, Azure Arc and now AI vendors like Anthropic, and what that means for agents.
Secrets work until they don’t
A service principal with a client secret works. It works right up to the moment it gets leaked, expires in the middle of an important job, or turns out to have no clear owner, no rotation plan and no one who knows where it is stored. Managed identity moves that whole burden to the platform. The secret still exists, but the developer never sees it. The admin’s job shrinks to control-plane questions: which resource, which identity, and what it can access. Arturo also hints at what comes next: binding managed identity tokens to the resource so a leaked token is useless anywhere else.
Beyond Azure
Not every workload or data source lives in Azure. Workload identity federation lets a workload present a token from an identity provider you already trust, such as AWS, Google Cloud, GitHub or Kubernetes, and exchange it for an Entra token with no secret involved. Azure Arc brings managed identity to servers outside Azure, including the one under your desk, which raised a hard design question for the team: what happens to the secret when the machine is in someone’s basement?
Coding agents default to secrets
Coding agents learned from years of examples full of client secrets and Key Vault plumbing, so that is what they produce. Merill has to push his own agents back towards workload identity federation every time. Arturo hit the same problem from the inside: when he asked a coding agent to build with Agent ID, it created a plain service principal and named it “blueprint”. The fix was rewriting documentation and shipping agent skills that teach coding agents the right pattern.
Why agent identities still allow client secrets
Merill asks the obvious question. If secrets are this bad, why can an agent identity have one? Arturo’s answer is compatibility. Agent identities already authenticate through a federated identity credential flow under the hood, but many places that call agents cannot obtain an OIDC token yet. Without secrets or certificates as a fallback, people would simply keep using app registrations.
Open standards are the way out
Agents now cross identity providers and clouds every day. Entra is leaning on open standards so they can do that without secrets or interrupting users: SPIFFE identities that can be exchanged for Entra tokens, and ID-JAG, which lets admins pre-consent so an agent can reach a service like GitHub or Slack without prompting the user.
Arturo’s advice for anyone building today is simple: whatever you can do to avoid having a secret, do it.

Is Each App in Entra ID Still Worth Governing?
App registrations and enterprise applications accumulate. Owners change. Projects and pilots end. Credentials linger. And stale or unused apps and their permissions can continue adding risk and governance overhead long after their purpose is gone.
ENow App Governance Accelerator helps you understand and act on:
* What is in your Entra ID application estate
* Who owns business and technical decisions and management?
* Which apps, permissions, and credentials need attention?
* What can be safely cleaned up to reduce your attack surface on a continuous basis as your tenant grows and changes?
Get the visibility and automated workflows you need to investigate application lifecycles at scale, clear out stale apps, and stop wasting time governing applications that shouldn’t still be there in the first place.
See it in Action
Subscribe with your favorite podcast player or watch on YouTube
About Arturo Lucatero
Arturo Lucatero is a Principal Product Manager at Microsoft working on Microsoft Entra Agent ID, where he focuses on giving agents a strong, governable identity and on the developer experience for building with it, including skills that teach coding agents to use Agent ID correctly. He joined Microsoft’s identity team after a re-org moved him there from Power BI, worked on Connect Health, and then helped Stuart Kwan launch Managed Service Identity, now managed identities for Azure resources. Most of his career has been spent modernising non-human identities, from managed identity and Azure Arc to workload identity federation.
LinkedIn - https://www.linkedin.com/in/arturo-lucatero/
Related Links
* Microsoft Entra Agent ID skill for coding agents, in GitHub Copilot for Azure (mentioned at 32:52) - https://github.com/microsoft/GitHub-Copilot-for-Azure/blob/main/plugins/azure-skills/skills/entra-agent-id/SKILL.md
* AI-guided setup for Microsoft Entra Agent ID, using the skill with GitHub Copilot (mentioned at 32:52) - https://learn.microsoft.com/en-us/entra/agent-id/agent-id-ai-guided-setup
* Ben Reader: Access Azure Key Vault from a local Kubernetes cluster with Azure Arc workload identity (mentioned at 22:32) - https://powers-hell.com/2026/08/26/access-azure-key-vault-from-a-local-kubernetes-cluster-with-azure-arc-workload-identity
* Ben Reader: Run a PowerShell workload on a local Kubernetes cluster that talks to Microsoft Graph (mentioned at 22:32) - https://powers-hell.com/2026/09/08/run-a-powershell-workload-on-a-local-kubernetes-cluster-that-talks-to-microsoft-graph
* Managed identities for Azure resources, formerly Managed Service Identity (mentioned at 04:50) - https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview
* Workload identity federation (mentioned at 15:18) - https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
* Workload Identity Federation for the Claude API (mentioned at 16:27) - https://platform.claude.com/docs/en/manage-claude/workload-identity-federation
* Agent identity blueprints in Microsoft Entra Agent ID (mentioned at 20:35) - https://learn.microsoft.com/en-us/entra/agent-id/agent-blueprint
* Access Azure resources with managed identity on Azure Arc-enabled servers (mentioned at 23:09) - https://learn.microsoft.com/en-us/azure/azure-arc/servers/managed-identity-authentication
* SPIFFE and SPIRE (mentioned at 27:41) - https://spiffe.io/
* Federate a SPIFFE/SPIRE workload identity with Microsoft Entra ID (mentioned at 29:25) - https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-spiffe-spire
* Pieter Kasselman: SPIFFE at the BotAuth BoF, IETF 123 (mentioned at 29:53) - https://datatracker.ietf.org/meeting/123/materials/slides-123-webbotauth-spiffe-at-the-botauth-bof-pieter-kasselman-00
* Identity Assertion JWT Authorization Grant (ID-JAG), IETF draft (mentioned at 30:21) - https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/
* Microsoft Secure Future Initiative (mentioned at 06:30) - https://www.microsoft.com/en-us/trust-center/security/secure-future-initiative
Related Entra.Chat Episodes
* One Compromised Agent ID Blueprint Can Cross Tenant Boundaries - https://entra.news/p/one-compromised-agent-id-blueprint
* From Windows Core to Leading Agent ID: Vince Smith’s Microsoft Story - https://entra.news/p/from-windows-core-to-leading-agent
* Attackers Are Targeting the AI Ecosystem You Cannot See - https://entra.news/p/attackers-are-targeting-the-ai-ecosystem
Chapters
00:00 Intro01:19 Arturo’s path from Intel to identity04:50 Launching Managed Service Identity07:06 Why MSI became managed identities09:41 How managed identity removes the secret14:31 Beyond Azure: workload identity federation17:08 Coding agents and the new secret sprawl20:01 When a coding agent fakes an Agent ID blueprint22:32 Managed identity anywhere with Azure Arc24:42 Why agent identities still allow client secrets27:41 Open standards: SPIFFE and ID-JAG31:48 What developers should do today
Podcast Apps
Entra.Chat - https://entra.chat
Apple Podcast - https://entra.chat/apple
YouTube - https://entra.chat/youtube
Spotify - https://entra.chat/spotify
Overcast - https://entra.chat/overcast
Pocketcast - https://entra.chat/pocketcast
Others - https://entra.chat/rss
Merill’s socials
YouTube - youtube.com/@merillx
LinkedIn - linkedin.com/in/merill
Twitter - twitter.com/merill
TikTok - tiktok.com/@merillf
Bluesky - bsky.app/profile/merill.net
Mastodon - infosec.exchange/@merill
Threads - threads.net/@merillf
GitHub - github.com/merill


Get full access to Entra.News - Your weekly dose of Microsoft Entra at entra.news/subscribe

Active Directory is not dead. It is nearly thirty years old, Microsoft is still shipping new capabilities and new telemetry for it, and most of the forests running today will outlive the people currently administering them. What has changed is that you can now test it the same way you test your cloud tenant.
Maester, the open-source PowerShell testing framework, added Active Directory coverage: 269 opt-in checks across 19 areas, from users, groups, computers and service principal names through GPO state, DACLs, DNS, trusts, replication and schema. They run against your domain, not your tenant, and they are off unless you explicitly connect to Active Directory.
Mike Soule, who wrote and validated that test suite, and Sam Erde, Microsoft MVP and author of DLLPickle, join Merill at HIP Conf in Nashville to go through what the tests cover, how to run them safely, and where the project is heading.
Sponsored by:
Is Each App in Entra ID Still Worth Governing?
App registrations and enterprise applications accumulate. Owners change. Projects and pilots end. Credentials linger. And stale or unused apps and their permissions can continue adding risk and governance overhead long after their purpose is gone.
ENow App Governance Accelerator helps you understand what’s in your Entra ID application estate, who owns it, which apps, permissions, and credentials need attention, and what can safely be cleaned up to reduce your attack surface on a continuous basis as your tenant grows and changes.
Get the visibility and automated workflows you need to investigate application lifecycles at scale, clear out stale apps, and stop wasting time governing applications that shouldn’t still be there in the first place.
Operational health is not the same as a security finding
The design decision that makes these tests usable is the split between operational patterns and security controls. Six groups nested in a row is not a vulnerability. Nesting is an intentional, functional capability. It is also nearly impossible to reason about when you are trying to work out where a permission actually comes from, and that is how incidents happen.
So not every test is pass/fail. Some exist to be investigated and monitored, and Maester’s tagging lets you baseline them and watch whether an anti-pattern is spreading or receding over time. The underlying guidance is a blend: years of health checks across dozens of forests, community research from teams like Semperis and SpecterOps, and Microsoft’s own documentation — which, for a product people keep declaring dead, is currently some of the best documentation and logging Microsoft ships. The new NTLM auditing in Windows Server is the example: the who, the why and the where of every NTLM authentication, instead of replaying events and correlating them yourself.
Maester is not trying to replace the likes of PingCastle, Purple Knight or Locksmith. Those tools offer real value, and the conversation now is about bringing those perspectives into one central platform.
The permissions you actually need
Everything the AD tests do is read-only. A plain domain user gets a surprising amount, because a directory is built to be readable — you will simply get a subset of the tests. The full set needs tier-zero read access, because some tests reach objects in the configuration container. In a tiered environment, that means running as a tier-zero admin from a privileged admin workstation.
Interactively, there is nothing to set up beyond line of sight to a domain controller, the ActiveDirectory module and PowerShell. The AD tests are excluded by default and have to be requested by tag. For automation, run a local runner, or give a container runtime a path back to a domain controller. Today the tests run as the logged-in user’s domain credentials; alternate credentials and group managed service accounts are on the road map.
Tiering, ESAE and the enterprise access model
There are no explicit tiering tests yet, but they are coming now that Microsoft has published implementation guidance. The history is worth knowing. ESAE — the Enhanced Security Admin Environment, the red forest — solved a real problem: inside Active Directory, a domain admin is trusted implicitly, so the source of authority needs to sit somewhere that is not self-referential. A separate management forest achieves that, at a cost in operational complexity that most organisations could not sustain. Microsoft has since moved to the enterprise access model, and in practice most teams landed in the middle: tiering based on access control, with tier zero for core identity infrastructure, tier one for servers, databases and applications, and tier two for workstations and the workforce.
The advice is not all-or-nothing. Any amount of effort you put into tiering is a good investment. Where Maester helps is codifying Microsoft’s recommended implementation as tests you can actually check yourself against, including the DACL and inheritance anti-patterns that accumulate through ordinary operations.
What is coming next
The dependency on the ActiveDirectory PowerShell module is on its way out. Almost all of this work is LDAP-level, so a .NET-based approach covers the vast majority of tests with no module dependency — which opens up Linux, macOS and non-domain-joined machines. Multi-domain aggregation is in progress; today a run covers a single domain at a time. And Maester 3 is being planned around a new engine for the built-in tests, with multi-threading and parallel execution, licensing handled centrally instead of inside every test, and Pester retained for backward compatibility and custom tests.
Subscribe with your favorite podcast player or watch on YouTube
About Michael Soule
Mike Soule is a Maester co-maintainer and National Director of Enterprise Architecture at Sentinel Technologies, where he works with enterprise customers on identity, cloud and security. He wrote and validated the Active Directory test suite that shipped in Maester 2.2 — 269 opt-in checks across 19 areas — and has been the project’s leading test contributor since the night after Maester’s launch talk at the PowerShell Conference, when he turned up the next morning with roughly thirty CISA tests already written.
LinkedIn - https://www.linkedin.com/in/mikesoule/
GitHub - https://github.com/soulemike
About Sam Erde
Sam Erde is a Maester co-maintainer and a Microsoft MVP, working at Patriot Consulting. He has spent more than twenty years in PowerShell, Active Directory, Group Policy, Exchange and Microsoft 365, contributes to open-source defensive tooling including Locksmith, and wrote DLLPickle, the module that gets you out of assembly version conflicts when several Microsoft modules are loaded in one session.
LinkedIn - https://www.linkedin.com/in/samerde/
GitHub - https://github.com/SamErde
Related Links
* Maester - open-source PowerShell test automation for Microsoft 365, Entra and now Active Directory (mentioned at 00:21) - https://maester.dev
* Introducing Maester 2.2 - the release that added 269 opt-in Active Directory checks across 19 areas (mentioned at 04:50) - https://maester.dev/blog/maester-2-2/
* Active Directory security testing in Maester - what the tests cover and how to run them (mentioned at 04:50) - https://maester.dev/blog/active-directory-security-testing/
* Maester on GitHub - source, tests and contribution guide (mentioned at 03:44) - https://github.com/maester365/maester
* Locksmith - Jake Hildreth’s AD CS assessment and remediation tool (mentioned at 05:11) - https://github.com/jakehildreth/Locksmith
* NTLM auditing enhancements in Windows 11 24H2 and Windows Server 2025 (mentioned at 09:53) - https://support.microsoft.com/en-us/topic/overview-of-ntlm-auditing-enhancements-in-windows-11-version-24h2-and-windows-server-2025-b7ead732-6fc5-46a3-a943-27a4571d9e7b
* AD DS tier model for privileged access security (mentioned at 24:47) - https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model
* Securing privileged access - the enterprise access model that replaced ESAE (mentioned at 25:23) - https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model
* DLLPickle - Sam Erde’s module for PowerShell assembly version conflicts (mentioned at 16:16) - https://github.com/SamErde/DLLPickle
* HIP Conference - Hybrid Identity Protection, Nashville, where this episode was recorded (mentioned at 01:18) - https://www.hipconf.com/
* PowerShell DSC (mentioned at 31:34) - https://learn.microsoft.com/en-us/powershell/dsc/overview
Chapters
00:00 Intro
00:40 Is Active Directory dead?
01:41 How Maester started and Mike’s overnight tests
04:50 Active Directory tests in Maester 2.x
05:03 How Maester compares to PingCastle and Locksmith
07:03 Operational health checks vs security findings
08:43 Where the AD guidance comes from
11:12 Running the tests and the permissions you need
13:53 Dropping the ActiveDirectory PowerShell module
15:18 One report for AD and cloud plus a Maester 3 teaser
17:20 Performance and memory in very large forests
20:23 Never run it on a domain controller
23:03 Multi-domain and multi-forest scans
24:14 Testing AD tiering and the enterprise access model
28:02 Beyond AD: DNS and Windows Server roles
28:50 Validating GPOs and desktop builds with Maester
31:25 Maester vs DSC and config-as-code
35:49 AD is not dead
Podcast Apps
Entra.Chat - https://entra.chat
Apple Podcast - https://entra.chat/apple
YouTube - https://entra.chat/youtube
Spotify - https://entra.chat/spotify
Overcast - https://entra.chat/overcast
Pocketcast - https://entra.chat/pocketcast
Others - https://entra.chat/rss
Merill’s socials
YouTube - youtube.com/@merillx
LinkedIn - linkedin.com/in/merill
Twitter - twitter.com/merill
TikTok - tiktok.com/@merillf
Bluesky - bsky.app/profile/merill.net
Mastodon - infosec.exchange/@merill
Threads - threads.net/@merillf
GitHub - github.com/merill


Get full access to Entra.News - Your weekly dose of Microsoft Entra at entra.news/subscribe