How to Prepare for Microsoft 365’s Secure by Default Changes in 2025 

Yesterday, Microsoft quietly dropped something big—and it’s going to impact every Microsoft 365 tenant starting this July. As part of their Secure Future Initiative (SFI), they’re rolling out a series of “Secure by Default” updates.  

TLDR: 

From mid‑July to August 2025, Microsoft will begin: 

1. Legacy browser authentication (RPS) is being blocked for SharePoint and OneDrive 
2. Blocking FrontPage Remote Procedure Call (FPRPC) protocol when opening Office files. 
3. Admin consent is now mandatory for third-party app access. 

These updates will start mid-July 2025 and be fully enforced by August. This is Phase 1 of Microsoft’s Secure Future Initiative (SFI)—a bold move to tighten tenant security whether you’re ready or not. So, no time like the present to get acquainted with what’s coming and how we can all be ready! 

Phase 1: Microsoft’s Secure by Default Changes

What was considered secure yesterday might become your weakest link tomorrow. That’s exactly what Microsoft is addressing with its Secure Future Initiative (SFI)—a multi-year effort to reimagine how security is baked into the design, development, and deployment of Microsoft technologies.  

Phase 1 focuses on modernizing default settings in Microsoft 365, with the goal of eliminating legacy risks and tightening control over third-party access. These new defaults are not just best practices, they’re becoming the baseline. 

The best part is these updates apply to all Microsoft 365 tenants, no special licenses required. 

Setting	What’s Changing	Why It Matters
Block legacy browser authentication (RPS) for SharePoint/OneDrive	Apps using RPS will be blocked from browser-based access. Admins can preemptively disable it via PowerShell using Set-SPOTenant.	RPS does not support modern authentication and is susceptible to brute-force and phishing attacks. Blocking it helps eliminate authentication bypass risks.
Block FPRPC protocol for Office file opens	The FrontPage Remote Procedure Call (FPRPC) protocol used for legacy file operations will be blocked by default. Organizations can manage this via web content filtering policies.	FPRPC is no longer supported and can expose document libraries to outdated attack vectors.
Require admin consent for third-party apps	Microsoft-managed App Consent Policies will be enforced. Users can no longer directly consent to third-party apps that request access to files and sites. Instead, a consent request will be routed to an admin.	Ensures that no application can access organizational content without explicit admin review.

Closing the Doors on Old Vulnerabilities 

1. Blocking Legacy Browser Authentication to SharePoint and OneDrive using RPS (Relying Party Suite): 

• The Problem: Many older applications still use legacy authentication protocols like RPS. The big issue with these is that they often don’t support modern security features like multi-factor authentication (MFA). Tools and scripts using RPS can be brute-forced; once compromised, intruders often gain access to sensitive content in SharePoint or OneDrive. If a legacy app has access to your SharePoint or OneDrive, it’s essentially a weak link in your security chain. 

• The Purpose: Blocking RPS for browser access to SharePoint and OneDrive forces applications to use modern, more secure authentication methods that can enforce MFA and other robust security measures, making it significantly harder for unauthorized access. 

2. Blocking FPRPC (FrontPage Remote Procedure Call) Protocol for Office File Opens: 

• The Problem: FrontPage Remote Procedure Call (FPRPC) is another blast from the past – a legacy protocol primarily used for remote web page authoring. While it’s not widely used for its original purpose anymore, the mere existence of such an outdated protocol in a modern environment can be a security risk. Legacy protocols, by their nature, are often less rigorously tested against modern attack vectors and can contain unpatched vulnerabilities. 

• The Purpose: By blocking FPRPC for opening Office files, Microsoft is removing another potential attack surface. This prevents any attempts to use this outdated protocol to interact with your Microsoft 365 files, further reducing your exposure to compromise. It’s about minimizing the unnecessary attack vectors in your tenant. 

3. Requiring Admin Consent for Third-Party Apps Accessing Files and Sites: 

• The Problem: This is a big one. Many users grant permissions to access all files or data to third-party apps without fully understanding the scope of the permissions they’re granting! This can lead to a massive overexposure of sensitive organizational content.  

• The Purpose: This change puts the power back in the hands of the IT administrators. Instead of individual users making potentially risky consent decisions, all requests for third-party apps to access files and sites will now go through an admin consent workflow. This ensures that every request undergoes admin review and is either approved or denied, significantly reducing the risk of accidental data leaks or malicious app infiltration. 

How to Prepare: Your Action Plan for a Smoother Transition 

A detailed action plan, aligning with the rollout timeline: 

• June 2025 — Begin assessments, review legacy protocol usage, and configure admin consent workflows. 
• Mid-July 2025 — Microsoft begins rolling out Secure by Default settings. 
• August 2025 — Rollout completes across all global tenants. 

Step 1: Audit Current Legacy Protocol Use: 

Understanding what’s currently in use in your environment is crucial. Start with reviewing legacy authentication protocols. 

To disable RPS-based authentication via PowerShell: 

Set-SPOTenant -LegacyAuthProtocolsEnabled $false

If you’re unsure whether these protocols are still being used, check audit logs or usage insights in the Microsoft 365 Compliance Center. 

Step 2: Block FPRPC Protocol Using Web Content Filtering: 

FPRPC (FrontPage Remote Procedure Call) is a legacy protocol used for old remote file editing scenarios. While it’s not something you can block directly via URL categories, Microsoft recommends using Web Content Filtering as a strategic method. 

Modern filtering engines (e.g., Microsoft Defender for Endpoint) provide deep packet inspection that can detect and block traffic tied to outdated or insecure protocols like FPRPC. Enabling content filtering: 

• Prevents insecure attempts to access Office files via FPRPC 
• Helps enforce secure communication standards 
• Reduces your organization’s exposure to legacy-based attacks 

Step 3: Configure Admin Consent Workflow in Microsoft Entra: 

This is perhaps the most hands-on step. If you rely on third-party apps, setting this up correctly is paramount. Start by reviewing which external apps currently have content access: 

Go to → Microsoft Entra Admin Center → Enterprise Applications → User Consent Settings to see which external apps have been granted site/content permissions. (I will write about it more clearly in a separate blog, for now, here is quick explanation on how to do it.) 

1. Go to entra.microsoft.com 
2. In the left pane, navigate to Identity → Applications → Enterprise Applications 
3. Click on Consent and Permissions → Admin Consent Settings 
4. Toggle “Users can request admin consent to apps they are unable to consent to” to Yes 

After enabling, set up your internal approval process and assign approvers. Make sure to save your configuration. It may take up to an hour for the workflow to become active. 

What Happens If You Don’t Prep? 

• Scripts, syncs, and backups relying on legacy authentication (RPS) will immediately break. 
• Users cannot install or grant permissions to new third-party apps accessing Microsoft 365, disrupting workflows. 
• Expect a spike in IT helpdesk tickets and user frustration due to unexpected access issues and service interruptions. 
• These default security changes apply to all Microsoft 365 tenants automatically—regardless of your licensing tier. 

This Gets Us Closer to Zero‑Trust 

For too long, we’ve operated on the premise that security is an add-on, a complex layer you build after everything else is set up. But the reality is, that mindset leaves us vulnerable. What Microsoft is doing here with Secure by Default feels like a real shift.  

Yes, there’s a bit of homework for us, like reviewing settings, talking with teams, rethinking how we manage apps. But consider it a huge step towards zero-trust.  

I can genuinely say, I’m here for it. This is a positive, necessary evolution, and by embracing it, we’re not just complying with new rules – we’re actively contributing to a more secure future for our organizations and for ourselves.