Token Protection: Registration Readiness

A user can complete strong authentication and still reach an application through an unprotected session flow. That is why a passkey rollout and a token-protection rollout need separate acceptance criteria.

Microsoft’s 12 October Entra roundup lists token-protection registration improvements as generally available.

The useful question is which existing devices can complete that registration, and which application journeys remain incompatible.

Start with the session you are protecting

Token protection is a Conditional Access session control for supported device-bound sign-in sessions. Its scope depends on the platform, application and resource. Native application support and the separate web application preview have different requirements.

Build your pilot around named journeys: Outlook reading a shared mailbox, OneDrive synchronising a project folder, or a particular administrative tool accessing its service. “Microsoft 365 works” is too vague to diagnose when one client succeeds and another fails.

Record the device operating system, join or registration state, application version, target resource and authentication broker. Give each journey an owner who can explain what a successful working day involves. Include less frequent tasks such as month-end reporting and opening another organisation’s shared resources.

This also prevents a misleading success result. A user signing into a supported application says nothing about a separate add-in that obtains its own tokens.

Separate three kinds of failure

Use a small readiness register rather than one percentage for the entire tenant.

The Windows deployment guide describes an inline registration prompt for eligible unregistered devices with the September 2026 Windows update. It also identifies unsupported deployment types and applications. Being Entra joined is therefore insufficient evidence by itself.

Collect the relevant sign-in event, its correlation identifier and the policy result. Review related requests when the same sign-in contains more than one. Ask the helpdesk to preserve these details before anyone removes and recreates a device registration. Rebuilding registration as the first troubleshooting step makes comparison harder and can disturb other working controls.

Treat Apple registration as a separate workstream

The Apple deployment guide requires managed device configuration and the Microsoft Enterprise SSO plug-in. It explains that some existing registrations can upgrade when users authenticate again. Report-only failures can include those upgrade candidates, so they should not all become permanent exclusions.

The same guide explicitly excludes Apple’s native Mail and Calendar applications. Tell affected users what will happen and agree the supported replacement before enforcing the policy. That is a compatibility decision; it does not justify a blanket claim about how every mail application stores its data.

Test a newly enrolled device and an existing device separately. A clean enrolment can hide the friction experienced by someone who has used the same phone for two years. Write the user instructions from the actual pilot prompt, including who to contact when the prompt differs.

Make the pilot produce a decision

Use report-only evidence to select the first enforcement group, then run a bounded enforcement test. The group should contain cooperative users with representative applications, rather than only administrators with unusually tidy devices.

Before the change, capture the policy configuration and its assignments. Confirm that another authorised administrator can restore the previous configuration if the pilot blocks essential work. The existing guide to moving Conditional Access from report-only to enforcement provides the broader change process.

For each journey, collect three observations: whether authentication completes, whether the expected session control is satisfied, and whether the application performs its actual business task. Keep the support effort alongside the technical result. A working flow that requires repeated manual repair is not ready for broad rollout.

An exception needs a named application, affected population, reason, compensating control and review date. Avoid an unrestricted exclusion group that becomes the default answer to every ticket.

Once the supported journeys pass, expand by another defined group and keep the same checks. Registration readiness is an input to enforcement, not a reason to assume the entire estate is protected.

References

• Microsoft — Microsoft Entra October 2026 announcement, published 12 October 2026. Accessed 17 October 2026.
• Microsoft — Token Protection in Microsoft Entra Conditional Access. Accessed 17 October 2026.
• Microsoft — Token Protection deployment guide for Windows. Accessed 17 October 2026.
• Microsoft — Token Protection deployment guide for Apple platforms. Accessed 17 October 2026.