Microsoft moved this deadline on 4 August. On 7 September the internet was still publishing the old date. Including Microsoft's own community pages.

Having found the authoritative record, you would like it to give you one date. It gives you four. All four are shown here, because the same thing will happen to you on the next change you look up.

ABT's reading, not Microsoft's: the four dates are two different things, and collapsing them into one deadline is the mistake to avoid. 5 October is a start, not a deadline. It opens the registration campaign, which is the only window in which this change can be made quiet rather than disruptive, so it is the date that actually determines how the November dates feel. An organisation that plans only against November skips the part that does the work.

Of the three November dates, 6 November is the earliest and the one to plan against. It is the structured act by field, so it is what an automated check surfaces, and a plan that meets it satisfies the other two. Enforcement beginning on a Saturday does not guarantee a quiet weekend, since a user locked out on the Saturday is locked out on the Saturday. What it means is that the volume reaches a staffed help desk on Monday.

What matters more than reconciling the four is noticing that none of them is September. Every published article we could find on the day this page was written was working from a schedule Microsoft had replaced five weeks earlier.

Microsoft publishes the revision promptly, marks it clearly, and often prints the old value beside the new one. The failure is structural, and it comes from three ordinary facts that combine badly.

• The authoritative record is tenant scoped. A Message Center notice is delivered into each tenant. You reach it by signing in to your own admin centre or by querying your own tenant through the API. There is no public URL for it. Search engines cannot crawl the tenant copy and a journalist cannot link to it. Third-party services do mirror these notices publicly, and those mirrors are indexable, so the content is not unreachable. What is missing is any link between the tenant record and the article that described an earlier version of it.
• The public record is a snapshot, and snapshots do not get recalled. An article describes the notice as it stood on the day of writing. When Microsoft revises the notice six weeks later, nothing reaches back into the article. It keeps ranking, keeps getting cited, and keeps reading as current, because it has a date on it and the date is the date it was right.
• Revision is routine. If Microsoft changed a schedule once a year you could treat a stale article as an edge case. Measured across a real tenant, a quarter of notices have had their timeline moved. At that rate, a secondary source on a Microsoft date can go stale without its author changing a word.

Stack those three and you get the situation on this page: the correct answer exists, is clearly written, is freely available to every affected organisation, and is missing from the pages most people will actually read.

It is also not a one-off. Notice MC1293480, covering the retirement of legacy transport layer security versions for POP and IMAP connections to Exchange Online, was published on 27 April 2026 and revised on 7 July 2026. Its body opens with the same sentence, word for word: "Updated July 7, 2026: We have updated the timeline." Two unrelated changes, two different Microsoft teams, the same phrase and the same silent revision.

The corollary for anyone running change management is worth stating carefully. An answer engine inherits this problem rather than solving it. A model answering "when does the SSPR change take effect" draws on the public web, where the superseded schedule is the more numerous answer, and agreement between sources is a poor guide when the sources share an origin. A model that happens to reach one of the specialist archives will get it right; one that reaches the news coverage will not. Neither outcome is something you can rely on in advance, which is the reason to check the tenant rather than the reason to distrust the tool.

Three examples is an anecdote. So on 7 September 2026 we walked the full Message Center collection for one Microsoft 365 tenant through the Graph API and counted, rather than continuing to collect stories.

Scope, stated precisely: this is 736 distinct notices retained and visible in a single tenant, spanning 21 September 2023 to 4 September 2026. It is not every notice Microsoft has ever sent, and a different tenant with different licensing and a different retention window will hold a different set. It is a large real sample rather than a census of Microsoft.

So roughly one notice in four carries Microsoft's own sentence saying its timeline moved, and among the changes Microsoft itself flags as major, closer to one in three were revised after issue. Revision is not the exception in this system. It is a normal part of how Microsoft ships. What that number measures is how often Microsoft moved something, not how often any particular article or process got it wrong; those depend on when the source was written and whether anyone re read it. The useful conclusion is narrower and still worth acting on: a published date is provisional often enough that treating it as final is a bet you will lose regularly.

Two cautions on reading those numbers, because the measurement is narrower than it first looks. The 25.0% counts notices whose body contains the phrase "we have updated the timeline", so it is a floor on schedule changes rather than a complete count, and the remaining 75% is "did not use that phrase" rather than a proven "never changed". Separately, a "(previously ...)" annotation marks any superseded value, not only a date. One of the notices in this set annotates a renamed feature that way.

Even so, the tail is long. Among annotated notices the median is two annotations and 56 notices carry three or more. An annotation count and a rescheduling count measure different things. A notice announces separate rollout rings, and one revision can stamp the same superseded value onto several of them at once, which is why a marker count runs ahead of the number of revisions that produced it.

This is the part worth keeping, whatever you do about the rest of the page. It needs no tooling and no budget.

• Get the notice identifier. Every Message Center item has one, in the form MC followed by seven digits. Most articles and vendor advisories quote it. If you have one, you can skip straight to it. If you do not, search the Message Center for the product name and read the titles.
• Open your own Message Center. In the Microsoft 365 admin centre, go to Health and then Message center. This is your tenant's copy. It is the record, and it is the version that reflects any revision Microsoft has made since the change was announced.
• Read the title before the body. If it begins with (Updated), the schedule or the substance has moved at least once since it was sent. Nearly a third of notices carry this. It is the single fastest signal that whatever you read elsewhere is suspect.
• Read the first line of the body. A revised notice usually opens with "Updated [date]" and a short statement of what changed. If it says the timeline was updated, any article written before that date carries the old schedule unless its author has revised it since.
• Search the body for the word "previously". This is the highest value thirty seconds on the page. Where Microsoft has moved a date it frequently prints the old value in brackets beside the new one. That is your confirmation that the figure circulating publicly was real and is now superseded, rather than someone's error.
• Collect every date and label what each one is. A single notice can carry a rollout or campaign start, an enforcement date, a structured act by field, and a headline date, and they will not all agree. Sort them into starts, which open a preparation window, and deadlines, after which something breaks. Record any differences you cannot reconcile rather than averaging them. ABT's recommendation: set your completion target at the earliest deadline, and diary the starts separately, because a start you miss quietly removes the runway that would have made the deadline easy.
• Record where you looked and when. Note the notice identifier and the date you read it. Microsoft revises these, so the answer you write in your change calendar today has a shelf life. Re read before any milestone you are relying on.

For an organisation with more than a handful of changes to track, the same records are available through the Microsoft Graph API, which is how the measurements on this page were produced. That path allows a scheduled check for newly revised notices rather than a person remembering to look. Mind the pagination warning above.

The free security assessment includes the check this page describes, run against your tenant rather than described to you. We read your Message Center, pull the notices that carry an action for your configuration and licensing, and report each one with its identifier, the dates exactly as your tenant states them, whether the notice has been revised since it was issued, and what it asks of you. Where a notice describes a change to something you rely on, we say what is currently configured and what will need to change.

Two things about that engagement. It is a technical review rather than legal or compliance advice, and the written output is yours whether or not you engage us for the work that follows. Some questions need your records as well as your tenant, such as which applications still send mail through a device using basic authentication, and we name exactly which ones to pull rather than guessing.

ABT manages Microsoft 365 tenants and hosts Azure environments for more than 750 financial institutions, so reading these notices against a regulated configuration is routine work here rather than an occasional project. ABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies.