Microsoft published a new Secure Future Initiative progress report in April 2025, and many admins are now asking which of the big promises have actually made a difference in their own tenants. Over the past year I've seen a clear shift in practice. Security-focused defaults and enforced controls have been arriving across Microsoft 365 and Azure tenants, sometimes quietly in the background and sometimes as visible, mandatory changes. Strong defaults still don't mean you can set security once and forget about it. Below I go through what has really changed, what you can copy for your own environment and where the responsibility is still firmly yours.

Secure by default has already arrived in customer tenants

If you look at a typical Microsoft cloud tenant today, you can't miss the move toward secure by default. Mandatory MFA for the Azure and Entra admin portals (details in my earlier post) and the fast rollout of Microsoft-managed Conditional Access policies (my practical take here) are simply part of daily life now. New tenants start with much stricter baseline settings. External sharing, legacy authentication protocols and anonymous sharing are locked down or switched off by default.

The Secure Future Initiative has also driven the steady retirement of legacy protocols. Basic Auth, POP and IMAP have been switched off or are on their way out, particularly in Exchange Online and Entra ID. Even the most change-averse environments have had to move as a result, though old automations that suddenly stop working can still catch people off guard. Teams that planned ahead had a much easier time.

Practical tip: If you still rely on POP, IMAP or Basic Auth, check for upcoming shutdowns. Exchange Online Admin Center → Settings → Email apps gives you a quick and accurate overview.

Admins can apply SFI principles beyond the defaults

The Secure Future Initiative isn't only about technical controls. It also promotes principles that admins should adopt deliberately. For me, secure by default is more than a slogan. Whenever I create new resources or identities, restrictive settings and least privilege should be the starting point. In particular, that means enforcing phishing-resistant MFA (FIDO2 security keys or passkeys) for every privileged account.

Another lesson I see confirmed every day is that production has to be separated from test and dev, without exceptions. No test users in production and no shared service accounts. Microsoft shows this more consistently now (Entra Administrative Units or Azure's SBUs, for example), but in the end each organization has to enforce the discipline itself. To be honest, comprehensive logging and extended retention are now mandatory too. If you stick with the default retention windows, you'll often be flying blind during an incident.

These SFI-inspired practices are worth turning into your own policies:

  • "Secure by default", meaning restrictive defaults for all new resources
  • Phishing-resistant MFA for every privileged account
  • Strict isolation between environments (prod, test, dev)
  • End-to-end logging with extended retention (e.g., Purview Audit)
  • Regular checks for legacy protocols and integrations, followed by their removal

You can also read my earlier post on the Secure Future Initiative and Microsoft's Zero Trust overview.

Some responsibilities stay with the customer despite better defaults

However much Microsoft raises the baseline, a tenant doesn't become secure on its own. In my projects, Microsoft-managed Conditional Access is a good place to start, but it almost never fits specific business or regulatory requirements exactly. Real security takes ongoing work from admins. That includes reviewing activity and audit logs, setting up custom alerts and adjusting policies as the environment changes.

Least privilege and app permissions are still largely a manual job. SFI has improved the defaults for new setups, but guest access, OAuth apps with too many permissions and forgotten legacy accounts still need governance on your side. Microsoft's guest access policies help, for instance, but they rarely clean up an old, entrenched tenant completely. You'll also need Access Reviews and some manual cleanup, as I describe in my guide to guest account cleanup.

SFI changes flow from Microsoft into customer tenants

The simple diagram below shows how Secure Future Initiative changes actually reach tenants. It traces how SFI measures are announced and delivered into Microsoft 365 and Azure, and where admins always have to step in to finish the job.

flowchart TD
    SFI["SFI measure announced"] --> MSCloud["Microsoft cloud update"]
    MSCloud --> Defaults["New secure defaults"]
    MSCloud --> Policies["Microsoft-managed policies"]
    Defaults --> Tenant["Customer tenant: settings updated"]
    Policies --> Tenant
    Tenant --> Admin["Admin: review & adjust"]
    Admin --> SecureOps["Own processes/policies"]

Figure: SFI measures travel from Microsoft's initiative to tenant settings and then into local admin processes.

In my view SFI provides momentum but no autopilot

The Secure Future Initiative has noticeably strengthened Microsoft's cloud security posture and pushed long-overdue changes into even the most stubborn tenants. What I keep seeing, though, is that a tenant only becomes properly secure when admins treat SFI principles as a starting point rather than a reason to stop thinking. If you rely on global settings alone, you'll have real gaps, especially in logging, guest access and the choice of MFA methods. SFI gives cloud teams a genuine tailwind in 2025, but the steering is still your job. If you make use of it, you'll stay ahead.