Entra’s federated sign-in: What changes for your business?

For most organisations, nothing will need to change. But if your environment still relies on older federation objects that allow cross-domain sign-ins, the update could interrupt authentication flows that have continued in the background for years.

It also fits a wider Microsoft direction of moving customers towards Entra ID for identity and access management, rather than continuing to invest in older federation models.

What’s actually changing

The enforcement applies to federated domains configured before December 2025 that still have an internalDomainFederation object.

If that object doesn’t match the user’s UPN domain, Entra will block the sign-in and return error AADSTS5000820. Microsoft has said that most tenants won’t be affected. The issue is more likely to surface where legacy federation settings are still in place or where cross-domain federated sign-ins are already happening.

That makes this a useful point to review older identity dependencies before the change takes effect.

If federated sign-ins begin to fail, support teams are likely to see the symptom first, while the root cause sits in federation design that may not have been reviewed for some time.

How this could impact Conditional Access policies

It’s also worth checking where Conditional Access sits in the sign-in flow. Conditional Access only applies once authentication reaches the point where those checks can run.

If the sign-in is blocked earlier because the federation object and UPN domain don’t align, the request never reaches that stage. That can leave teams with a gap between the protection they believe is in place and the path the sign-in is actually taking.

In reality, the majority of organisations are unlikely to be affected and no action will be needed.

The environments most likely to need review are those with older AD FS-era trusts, domain changes, inherited identity architecture from mergers, or other third-party federation dependencies that have stayed in place over time. AD FS is the most common example in the real world, but the same principle applies more broadly wherever legacy federation relationships are still active.

What organisations should do now

Start by identifying which federated domains are still active in your tenant and when they were configured.

From there, map which users, applications and sign-in paths still depend on them, then test whether the UPN domain aligns with the federation object that will now be enforced. If Conditional Access depends on a particular authentication path, check that it will still evaluate as expected once the new validation behaviour is in place.

There are ways to adjust policy behaviour through configuration, but doing so weakens the control Microsoft is introducing. That makes it a short-term workaround rather than a long-term solution.

The safer route is to:

• Correct the federation mapping
• Remove outdated dependencies
• Align authentication paths with how identity is actually structured today

A minor change and a reminder to review your estate

On paper, this is a narrow enforcement update.

That does not make this a deprecation story. But it is another example of Microsoft tightening older identity paths and pushing organisations to review whether legacy federation still reflects how access should work today.

But it does offer organisations a timely opportunity to check if your federation model still reflects how access works across your organisation.

So, rather than reacting to a new enforcement issue, use it as a prompt to check what’s running undetected in the background.

And as always, if you need support reviewing your federation configuration, or have any other queries about your existing Entra estate, please contact the Kocho team.

How to stay protected

For most devices, Microsoft will deploy the updated certificates automatically through Windows monthly updates, but not all devices qualify for automatic rollout. The certificate update involves firmware-level changes and some hardware requires manufacturer patch before it can take effect.

The steps are straightforward:

• Keep Windows Update enabled so your device can receive the updated certificates.
• Apply any required OEM firmware (UEFI/BIOS) updates, some devices need this before the certificate update can take effect.
• Don’t disable Secure Boot, as doing so removes the protections this update is designed to preserve.
• If devices haven’t received the new certificates after Windows Update has run, check with your OEM, particularly for older hardware.

For Azure Virtual Desktop environments, additional guidance applies. Devices using Azure Compute Gallery images with Secure Boot enabled should have the 2023 certificate update applied to the golden image before it is captured, and Trusted Launch must be enabled for the update to take effect at image level.