This article explains how to prevent Word from using the cloud and enforce local saving.
The Opaque Strategy of Microsoft Office
The evolution of Microsoft Office tools is accompanied by a gradual shift toward the cloud. In practice, this transition does not occur in a transparent manner. It operates in a largely opaque way, without the user being clearly informed of what is actually happening.
When opening or saving a document, the interface gives the impression that the work is being done locally, on the workstation. However, in many cases, this is not the reality. Files are hosted on remote services, notably SharePoint, even though the user believes they are working on their own computer.
The issue lies not only in remote storage, but in how it is presented. The Word interface, combined with that of Windows, obscures the true source of the files. File paths, shortcuts, and suggested locations replicate a local structure, when in fact they correspond to a cloud-based infrastructure.
This presentation creates structural confusion. By default, everything is organized so that the user interprets their work as local, even when it is not. Only experienced users are able to identify the signs of remote storage. For others, the system maintains this ambiguity.
An element that makes the situation even more problematic is that, even when the user has never explicitly requested to use SharePoint, nor subscribed to the service, it can still be activated in the background.
In my case, I use a perpetual version, not tied to Office 365. I have never subscribed to Office 365 nor requested the activation of SharePoint. Yet, a SharePoint space was associated with my account and used without any explicit configuration on my part.
This is precisely where the core issue lies.
The user believes they are working locally, while their files are progressively associated with a remote infrastructure. This behavior can persist even when Word is configured to prioritize local saving.
From a technical standpoint, this type of behavior cannot be involuntary. Software does not produce conditional behavior without implemented logic. Any action dependent on a state—connection, account, synchronization—necessarily relies on code that has been designed, integrated, and validated.
This means that the mechanisms observed are not anomalies, but structural behaviors.
At first, cloud integration may appear beneficial. It enables automatic backup and increased accessibility. However, this logic is based on a fragile balance.
Without vigilance, files eventually cease to truly exist locally. The user then loses direct control over their data.
The consequences are tangible. In the absence of an Internet connection, access to documents can become limited or even impossible. A strategy initially intended to secure data—maintaining both a local and a remote copy—can ultimately produce the opposite effect.
This is why it becomes essential to understand these mechanisms and implement measures to regain real control over where files are stored and how they are accessed.
Author’s Perspective
Beyond the technical aspects, this situation raises a fundamental question for any author.
Writing is not simply about producing text. It involves building, structuring, revising, refining, and versioning—sometimes over months or even years. A manuscript is not just another file. It is a work in progress, an evolving piece, a coherent whole that depends on mastering every version.
In this context, control over file location is not a minor technical detail. It is a working condition.
An author must be able to know, at any moment, where their documents are stored, which versions exist, and on what medium they are accessible. They must be able to work without depending on an Internet connection, without uncertainty about the actual state of their files, and without any invisible intermediary.
When this control becomes unclear, the entire writing process is weakened.
The risk is not merely technical. It is structural. Losing control over one’s files means losing control over one’s own work. It introduces dependency into a process that should remain autonomous.
This is precisely why these mechanisms are problematic.
Not because they exist, but because they impose themselves without being clearly exposed, and fundamentally alter the relationship between the author and their working environment.
For an author, the question is not whether to reject the cloud. It is to decide when, how, and under what conditions it is used.
Blocking SharePoint Locally on Windows (Without External Services)
It is possible to effectively limit Word’s access to SharePoint without relying on any external service. This approach is based on a simple principle: regaining control at the network level.
1. Blocking SharePoint via Windows Firewall
This method operates directly at the network level. Unlike Word’s settings, it cannot be bypassed by the application.
Steps:
- Open the Start menu and search for “Windows Defender Firewall with Advanced Security”
- Click on “Outbound Rules”
- Click on “New Rule”
- Select “Custom”
- Choose “This program” and specify the path to Word (WINWORD.EXE)
- Select the TCP protocol
- Specify remote port 443
- In “Scope,” add the following IP addresses:
13.107.0.0/16
40.96.0.0/13
52.96.0.0/12
These ranges correspond to Microsoft infrastructure (Azure / SharePoint).
- Select “Block the connection”
- Apply to all profiles
- Name the rule and validate
Result: Word can no longer establish connections to these services, even if its interface attempts to do so.
2. Clearing the DNS Cache
- Open Command Prompt as administrator
- Run:
ipconfig /flushdns
3. Verification
Go to:
The site should be inaccessible.
Technical Limitations
The firewall remains the most reliable level of control, as it directly governs network communications. However, Microsoft may evolve its infrastructure, particularly the IP ranges used.
Conclusion
Application settings and standard configurations are no longer sufficient to control the behavior of modern cloud-oriented software.
Only network-level blocking allows for real control to be regained.
This approach ensures that files remain accessible locally, independently of any external connection.
Like all the tools we use, it is essential to understand how they actually function—such as the WordPress sitemap, which is not directly exposed to the user, of little structural use, and can, in some cases, be harmful.
Important Point to Understand
The activation of a Microsoft account, even without an Office 365 subscription, may lead to the automatic creation of a SharePoint space associated with the user.
This process can occur without explicit request or visible configuration.
This means that a user may end up with an active cloud infrastructure without having intentionally set it up.