Hero image generated by ChatGPT
This is a personal blog and all content herein is my own opinion and not that of my employer.
Enjoying the content? If you value the time, effort, and resources invested in creating it, please consider supporting me on Ko-fi.
What The Entra Fudge?!
There’s a moment every identity or cloud security practitioner eventually hits.
The moment where you do everything right — follow the documentation, apply least privilege, design careful Conditional Access policies — and the platform still behaves in a way that makes you stop, squint, and mutter:
“…what the Entra fudge?”
This series exists for those moments.
What The Entra Fudge?! is a collection of short, practical deep-dives into Entra ID, Conditional Access, and Microsoft cloud identity behaviours that only become obvious once you leave the documentation happy path and start looking at real sign-in logs, real tokens, and real platform flows.
These posts are not vulnerability disclosures.
They’re not product bashing.
And they’re definitely not “Microsoft bad” hot takes.
Instead, each entry focuses on:
- A reasonable security assumption many of us make
- What actually happens at runtime
- Why that behaviour makes sense at scale
- And how to design securely despite the surprise
The goal isn’t to point fingers — it’s to fix mental models.
If you’ve ever wondered why a Conditional Access policy didn’t quite do what you expected…
If you’ve ever felt like identity boundaries were fuzzier than the diagrams suggest…
Or if you’ve ever stared at Entra sign-in logs thinking “this can’t be right”…
You’re in the right place.
Welcome to What The Entra Fudge?!
Allow One, Allow All: When Conditional Access Loses the Plot
There’s a moment every cloud security professional recognises.
It’s when you’re staring at Conditional Access sign-in logs thinking:
“That… can’t possibly be right.”
Not because the logs are wrong.
But because the mental model you were operating under just quietly collapsed.
This post is about one of those moments.
Specifically: how Dev Box, Azure Virtual Desktop (AVD), and Windows 365 all authenticate through the same first-party Entra application — and why that turns “carefully scoped Conditional Access” into something much closer to “all or nothing” than most people realise .
No pitchforks. No “Microsoft bad” hot takes. No vuln claims. Just a calm walk through what’s actually happening…
The comforting lie we all tell ourselves
Most Conditional Access designs implicitly rely on this idea:
Different workloads → different apps → different policies
So we write policies like:
- Allow Dev Box from BYOD, but only for engineers
- Require compliant devices for Windows 365
- Apply stricter controls to AVD
And on paper?
That looks entirely reasonable.
The problem is that Conditional Access does not enforce “workloads”.
It enforces application identities.
And sometimes - increasingly often - those are not the same thing.
The “wait… they all use what?” moment
Here’s the punchline first:
**Dev Box, AVD, and Windows 365 all authenticate through the same Entra first-party application set and shared broker.**
Different portals.
Different documentation.
Different perceived products.
Same app set. Same broker. Same CA boundary.
Which means:
**If you allow that app for one scenario, you’ve implicitly allowed all of them.**
Not because you misconfigured anything.
Not because you missed a checkbox.
But because the distinction simply doesn’t exist at the authentication layer.
Why this matters more than it sounds
Let’s say you follow Microsoft guidance to enable BYOD access to Dev Box.
You carefully:
- Create a Conditional Access policy
- Allow the relevant app from unmanaged devices
- Add MFA, maybe sign-in risk controls
- Feel reasonably confident
What you think you’ve done:
“Allowed engineers to access Dev Box from personal devices.”
What you’ve actually done:
“Allowed access to the shared virtual desktop broker used by Dev Box, AVD, and Windows 365.”
Conditional Access cannot see:
- Which pool
- Which service
- Which justification
- Which downstream desktop experience
It only sees:
“User is authenticating to this app.”
And once that app is allowed, the door is open.
What makes this especially problematic is that, per Microsoft’s own documentation, all three services rely on an overlapping set of Entra first-party applications and brokers:
AVD https://learn.microsoft.com/en-us/azure/virtual-desktop/set-up-mfa
- Azure Virtual Desktop (app ID 9cdead84-a844-4324-93f2-b2e6bb768d07) - may still be called Windows Virtual Desktop in your tenant.
- Windows Cloud Login (app ID 270efc09-cd0d-444b-a71f-39af4910ec45)
W365 https://learn.microsoft.com/en-us/windows-365/enterprise/set-conditional-access-policies
- Windows 365 (app ID 0af06dc6-e4b5-4f28-818e-e78e62d137a5)
- Azure Virtual Desktop (app ID 9cdead84-a844-4324-93f2-b2e6bb768d07) - may still be called Windows Virtual Desktop in your tenant.
- Windows Cloud Login (app ID 270efc09-cd0d-444b-a71f-39af4910ec45).
Dev Box https://learn.microsoft.com/en-us/azure/dev-box/how-to-configure-intune-conditional-access-policies
- Windows 365 (0af06dc6-e4b5-4f28-818e-e78e62d137a5)
- Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)
- Microsoft Remote Desktop (a4a365df-50f1-4397-bc59-1a1564b8bb9c)
- Windows Cloud sign-in (270efc09-cd0d-444b-a71f-39af4910ec45)
This isn’t theoretical — it’s systemic
If this feels familiar, that’s because we’ve seen the same pattern elsewhere:
- Microsoft Graph collapsing behind Office 365 (upcoming post)
- Azure Resource Manager required for UI enumeration, not actual operations (upcoming post)
- Portal-driven impersonation instead of backend S2S calls (upcoming post)
Different surface area.
Same architectural trade-off.
Identity becomes a monoculture — convenient, scalable, but extremely coarse from a security policy perspective .
Why Conditional Access struggles here
Conditional Access is very good at answering questions like:
- Who is the user?
- What app is this?
- Is the device compliant?
- What’s the sign-in risk?
It is not good at answering:
- What will the user do next?
- Which workload will they land in?
- Is this Dev Box or a Cloud PC?
Because those decisions happen after authentication, inside the platform.
CA enforces the front door.
Microsoft workloads increasingly share the same lobby
.
“So what are we supposed to do — not use Dev Box?”
No.
And this is the important bit.
This post is not saying:
“Conditional Access is useless.”
It’s saying:
**Conditional Access alone is not sufficient when multiple workloads share the same identity boundary.**
The fix isn’t panic.
It’s layering.
How to secure this properly (given reality)
1. Stop treating CA app targeting as workload isolation
If multiple services share an app:
- Don’t pretend CA can differentiate them
- Design policies assuming blast radius, not precision
Ask:
“If this app is allowed, what else does that implicitly enable?”
Document that explicitly.
2. Use CA to establish who — not where they land
Conditional Access is excellent at enforcing:
- Strong MFA
- Authentication strength
- Risk-based access
- User scope (roles, groups)
Use CA to answer:
“Is this a trustworthy user session at all?”
Not:
“Which virtual desktop flavour is this?”
3. Push enforcement down into the workload
Once identity collapses, the workload must pick up the slack .
For virtual desktops, that means:
- Session host configuration
- Network controls
- Privilege separation
- Local hardening
- Resource access policies
Zero Trust doesn’t end at sign-in
.
It just starts there
.
4. Be extremely cautious with BYOD allowances
If you allow a shared broker app from unmanaged devices:
- Assume all associated workloads are reachable
- Compensate accordingly:
- No standing admin
- Strong PIM
- Short session lifetimes
- No credential material exposure
BYOD + virtual desktops is viable — but only if you treat it as high-trust access.
5. Read Microsoft docs… but verify behaviour
This one’s uncomfortable, but necessary.
Documentation often describes intended usage, not enforcement reality.
Before loosening a CA control:
- Test sign-in logs
- Check which app actually appears
- Verify whether access paths collapse elsewhere
If the portal works without ARM…
If the pool works without enumeration…
If multiple services share one app…
That’s the truth you design for.
This isn’t a mistake — it’s a trade-off
To be clear: none of this is because engineers are careless.
This is what happens when:
- Platforms optimise for scale
- Identity is reused for efficiency
- UX simplicity beats policy granularity
From Microsoft’s perspective, shared brokers make sense.
From a defender’s perspective, they demand honest threat modelling.
The danger isn’t the architecture.
The danger is believing you have isolation when you don’t .
The real takeaway
If there’s one line I want people to remember, it’s this:
**If multiple workloads authenticate through the same Entra app, Conditional Access cannot enforce boundaries between them — only trust in the session itself.**
Once you internalise that, a lot of confusing behaviour suddenly makes sense.
And your security designs get much calmer, much faster.
Final thought (and a little side-eye)
Conditional Access is still one of the most powerful control planes we have.
But it’s not magic.
And it’s not psychic.
When identity collapses, policy must shift from precision to resilience.
Allow one?
Assume you’ve allowed all.
Then secure accordingly.