Somewhere in your organisation there’s probably a mailbox receiving a weekly email from Microsoft 365 that nobody opens. It isn’t laziness. The digest is long and written for every kind of customer, so most of it won’t apply to you. But the same feed is where Microsoft tells you that the way your people sign in is about to change, and that’s the one you can’t afford to miss.
The aim isn’t to read everything. A single change, like the Teams messaging safety change, is easy to follow once someone points it out. The harder part is making sure the right person sees the few notices that matter and that somebody decides what to do before the date arrives. Everyday housekeeping is in our general Microsoft 365 tips, and our Microsoft 365 and Azure page covers the tenant work we do.
Where the notices come from, and who gets them
Microsoft 365 has two places worth knowing about, and they answer different questions. The Message center (Microsoft’s spelling) sits under Health in the admin centre and is for what’s coming. Service health, in the same menu, is for what’s gone wrong, though planned maintenance isn’t shown there. Microsoft’s Message center page also refers to an AI at Work roadmap, which is worth knowing exists.
The part that catches people out is who receives what. The weekly Message center digest is on by default for each admin and goes to that admin’s primary address, with separate emails for major updates and for data privacy messages. Each admin sets their own preferences and can add up to two addresses. So if the person who set up your tenant (your organisation’s own slice of Microsoft 365) has left, or their mailbox is a catch-all, the notices may be arriving somewhere nobody looks.
Roles matter too. Several admin roles can’t open Message center at all, including Conditional access administrator, Intune service administrator, Compliance administrator and Privileged role administrator, so check that whoever manages your sign-in rules can see it. If you want someone to read and share the notices without holding any other admin power, there’s a Message center reader role for exactly that. Service health email works differently, because each admin has to switch it on and can give up to two addresses, and the Service Support admin and Helpdesk admin roles can view it.
What deserves a second look
Message center carries tags, and a few of them do most of the work for you. A Major update is communicated at least 30 days in advance when action is required, and there are separate tags for Retirement and for changes with an Admin impact. Microsoft says the Act by column is rarely used, so when a date does appear there, read that notice first. Plan for change isn’t shown by default but you can add it through the column chooser, and Microsoft describes it as covering changes that might need you to act to avoid disruption.
Licence, price and bundle changes need a different habit, because the notice may reach whoever bills you rather than the tenant’s admins. Find out whether that’s Microsoft directly or a reseller, and make sure their emails go to a shared mailbox that more than one person can see.
Three real changes, and what they show
These three show the shape a change takes. They aren’t a to-do list.
The first is mandatory multifactor authentication for admin portals, which means a second proof of identity at sign-in. Microsoft’s page describes it starting in October 2024 for the Azure portal and related admin centres, reaching the Microsoft 365 admin centre in February 2025 and the Azure command-line tools from 1 October 2025. It also notes that the last date had changed, and that emergency access accounts weren’t exempt. Read the page rather than the headline, and check that your emergency accounts can complete MFA.
The second is security defaults, a preconfigured set of sign-in protections that tenants created on or after 22 October 2019 might already have on. Microsoft says it periodically notifies customers before turning them on automatically, but only where there are no Conditional Access policies (rules that decide when someone can sign in and what they must prove), no premium licences and no active use of legacy authentication. That last term means older sign-in methods, such as the IMAP, SMTP and POP3 mail protocols, that can’t ask for a second step. Security defaults block them, and an old scanner-to-email setup is the kind of thing that can depend on them.
From 1 July 2026, all new tenants block device code flow as part of security defaults, so in a new tenant with security defaults on, anything that relies on device code sign-in will fail. That’s a sign-in method for devices with little or no keyboard, such as printers or smart TVs. Either way, the practical point is to find out what in your office depends on these things before a notice arrives.
The third is Microsoft-managed Conditional Access policies. Microsoft says it creates these in eligible tenants, depending on licensing (the page names Microsoft Entra ID P2 or Microsoft 365 Business Premium), in report-only mode, where a policy records what it would have done without enforcing it. Left alone, one is switched on no less than 30 days later, with emails and Message center posts two weeks beforehand. You can turn one on sooner or set it to Off. Two weeks is a short window if the email sits unread, so we’d include the policy list in the monthly check, where these show Microsoft as creator.
A monthly routine and a change log
This routine is ours rather than Microsoft’s, and for a small organisation it’s a sound starting point. Once a month, a named person opens Message center, filters for Major update, Retirement and Plan for change, looks at anything due in the coming month or so and reads the Act by dates. They glance at the last 30 days of Service health history, check the Conditional Access policy list for anything created by Microsoft and confirm the digest recipients are still people who work with you. The tenant owner, usually whoever is accountable for the business, decides what’s worth acting on, and whoever pays the bills watches the licence emails.
Every item that matters goes into a short log. Here’s an illustration with a made-up entry and a placeholder message ID.
| Logged | Message ID | What changes | Affects us? | Act by | Owner | Checked and decided |
|---|---|---|---|---|---|---|
| 1 Nov | MC000000 | Example: a legacy mail protocol is switched off | Yes, the scanner | 30 Nov | Admin | Sign-in logs checked and scanner reconfigured by 12 Nov |
It’s a spreadsheet and ten minutes, and it earns its keep a year later when somebody asks why a setting changed.
Test it before your people meet it
Where a change is a Conditional Access policy, report-only mode lets you see what it would do without doing it. For Microsoft-managed policies, Microsoft’s page points to a Policy impact tab and the sign-in logs for the results. You can also pilot a policy with a handful of people across different roles, and we’d do that a week before the date.
Security defaults can’t be trialled on a few people, because they’re on or off for the whole tenant. Instead, find what depends on the thing being switched off (the scanner, the shared mailbox, an old app) and test that first. A good way to find them is to look in the sign-in logs for older protocols, and reconfiguring the device before the date is the fix. Message center’s Status for your org field (Scheduled, Rolling out or Launched) can help you tell when a feature is likely to reach you, though the page says it’s only available for limited announcements.
Writing the log is the easy part. Working out what each change does to your own sign-in rules is harder, and if you’d like a second opinion on a notice you’re not sure about, talk to us and we’ll look at it with you.
