A recent wave of SharePoint-targeted attacks reveals dangerous immaturity in how organizations govern collaboration platforms. Despite being central to digital workflows, SharePoint setups often suffer from weak cyber hygiene, lack of ownership, and outdated or non-existent data retention policies. This article evaluates how these weaknesses clash with NIS2 maturity expectations — and how organizations can take immediate action to avoid being the next victim.
I was was one of the happy few present at the original launch of SharePoint Portal Server 2001, Microsoft’s first on-premises collaboration platform released in March 2001. Early in my career, i contributed to the SharePoint governance setup at the Flemish Government, working as consultant for the Belgacom SharePoint division.
Over two decades later, despite the evolution of Microsoft 365 and the flood of available best practices, one thing remains disappointingly consistent: organizations still struggle with weak SharePoint configurations, missing ownership, and fragile governance — making it a recurring target in the cyber threat landscape.
With firsthand experience from version 1.0 through the NIS2 era, i want to bring a sharp and objective lens to evaluating how far we’ve come — and how far we still have to go.
“SharePoint: The Silent Exposure Point in Your NIS2 Maturity Journey”
As the cybersecurity community races to contain the latest SharePoint exploitation campaigns, a sobering truth emerges: for many organizations, SharePoint is the blind spot in their NIS2 readiness. Whether deployed on-premises or in the cloud, SharePoint portals too often evolve into a labyrinth of unaudited access, expired links, orphaned documents, and uncontrolled external sharing. The result? A governance vacuum that violates not only good security practices but the core requirements of NIS2 Articles 20 and 21.
Low Maturity Triggers: A Chain of Failures
The exploitation of SharePoint systems isn’t just about a vulnerability — it’s the consequence of a cumulative failure in information governance and basic cybersecurity hygiene:
- Lack of role clarity: No single team or owner manages SharePoint security and data lifecycle.
- Missing or outdated policies: No rules on who can create sites, share data, or enforce encryption.
- Shadow IT: Users create anonymous SharePoint sharing links outside the purview of IT or security.
- No retention or classification model: Business-sensitive data sits indefinitely in default libraries without audit logging or cleanup.
Under NIS2, these conditions represent a failure to manage digital operational resilience and inadequate risk management, both of which are explicitly regulated in Article 21(2).
Mature Organizations Demonstrate These SharePoint Defenses
High-maturity SharePoint environments, aligned with NIS2 expectations, typically show the following traits:
- Integrated Governance: SharePoint is not a side-project; it’s part of the organization’s Information Security Management System (ISMS), with site lifecycle, permissions, and DLP rules embedded.
- Multi-Factor Authentication (MFA): Enforced at every level, with conditional access policies for guest and external users.
- Encryption Hygiene: Local encryption is applied to key document libraries; storage is backed by secure key management (e.g., Azure Key Vault).
- Document Classification & Retention: Each document has a lifecycle policy and classification tied to risk level and regulatory exposure.
- Audit Trail & Logging: Events are monitored and integrated with SIEM or Microsoft Defender for Cloud Apps.
- Incident Response Hooks: SharePoint access abuse or privilege escalation is included in the organization’s security playbooks.
Why a SharePoint shows a Maturity level that Matters for NIS2
In the lens of NIS2, the maturity level of your SharePoint environment influences compliance posture across multiple domains:
| NIS2 Article | SharePoint Maturity Connection |
| Art. 21(2)(a) – Risk management | Governance and access reviews for digital services like SharePoint |
| Art. 21(2)(b) – Incident handling | SharePoint abuse detection and incident response inclusion |
| Art. 21(2)(e) – MFA implementation | Demonstrating full MFA enforcement, even for federated/cloud accounts |
| Art. 21(2)(g) – Cryptography | Use of local encryption and cloud-native controls (BitLocker, Azure RMS) |
| Art. 21(2)(i) – Policies and procedures | Documented SharePoint usage, sharing, and retention policies |
Action Points for CISOs & DPOs
To move from reactive to proactive SharePoint defense:
- Inventory all SharePoint sites (on-prem & cloud) and map their data exposure.
- Enforce MFA on all accounts, including third parties and external users.
- Apply encryption-at-rest and in-use using available Microsoft 365 security tools.
- Create a SharePoint-specific governance policy aligned with data retention, classification, and security controls.
- Monitor abnormal access using Defender for Office/M365 or third-party SIEM integrations.
- Test SharePoint incident scenarios as part of your NIS2-aligned incident response drills.
Conclusion: SharePoint Isn’t a Document Folder — It’s an Attack Surface
The recent exploit campaigns are not just technical alerts; they’re maturity audits in disguise. Under NIS2, organizations must take full ownership of every digital service they operate or expose. SharePoint is no exception.
Cybersecurity is governance. Maturity is visibility. And SharePoint, when ignored, becomes a liability.
Are All SharePoint Sites Hackable? A Reality Check
No, not all SharePoint sites are inherently hackable — but every SharePoint site is potentially exploitable if the surrounding security architecture, governance, and hygiene are weak.
Whether on-premises (e.g., SharePoint Server) or cloud-based (e.g., SharePoint Online in Microsoft 365), the exploitability of a SharePoint portal depends entirely on its configuration, hardening, and surrounding security controls.
SharePoint Can Be Secured — When the Right Defenses Are in Place
Organizations with strong cyber hygiene and a layered defense-in-depth model are significantly more resistant to SharePoint-based attacks. These setups typically include:
- Full Multi-Factor Authentication (MFA)
- Enforced for all users (internal and external)
- Conditional Access policies to restrict legacy or insecure clients
- Blocking anonymous access links
- Least Privilege and Role-Based Access Control
- Use of security groups or Azure AD roles to limit access
- No reliance on default “Everyone” or “All Authenticated Users” groups
- Regular access reviews and revocation of unused permissions
- Data Classification and Sensitivity Labels
- Automatic or manual labeling of sensitive content
- Application of DLP rules based on labels
- Encryption and access restrictions tied to sensitivity
- Monitoring and Threat Detection
- Use of Microsoft Defender for Cloud Apps and Purview
- Alerts for unusual download volumes, privilege escalations, and geo-anomalies
- Logs integrated with SIEM for threat hunting
- Regular Updates and Hardening for On-Premise Installations
- Application of latest security patches
- Deactivation of legacy services and endpoints (e.g., InfoPath, WebDAV, SOAP APIs)
- TLS enforcement and hardened server configuration
Who is in the hacking Dance? The Low-Hygiene Portal Owners
Unfortunately, many SharePoint site owners — especially in decentralized or hybrid organizations — “are in the hacking dance” when it comes to cybersecurity. Here’s where it typically breaks down:
- No formal ownership of SharePoint sites (orphaned sites with no active admin)
- Uncontrolled sprawl of collaboration spaces and guest users
- Open sharing enabled for external links with no expiration or oversight
- Disabled or unenforced MFA, often for legacy apps or service accounts
- No audit trails, retention policies, or security classification
This lack of basic security controls turns SharePoint from a collaboration tool into an exploitable attack surface — often without the organization even knowing where or what is exposed.
NIS2 Compliance Lens
Under NIS2 Article 21, this situation directly touches on:
- 21(2)(a): Risk Management Measures – Failure to classify SharePoint exposure = weak risk posture
- 21(2)(e): Use of MFA – Absence or poor enforcement violates a core NIS2 requirement
- 21(2)(g): Cryptography and Data Protection – No local encryption = lack of essential controls
- 21(2)(i): Policies & Procedures – Lack of governance structure = systemic immaturity
Conclusion: SharePoint Security is Not Binary
To summarize:
| Statement | Reality |
| “All SharePoint portals are hackable.” | ❌ False – Only poorly governed or misconfigured ones are exploitable |
| “Cloud SharePoint is safe by default.” | ⚠️ Partially true – But defaults can still be misused or bypassed |
| “Good cyber hygiene makes a difference.” | ✅ Absolutely – Mature orgs with layered security are far less likely to be compromised |
Bottom Line:
A SharePoint portal is only as secure as the governance, visibility, and controls surrounding it. NIS2 doesn’t ask, “Did you patch?” — it asks, “Can you prove maturity and resilience?” In that test, good SharePoint owners don’t miss the dance — they orchestrate it.
An attacker targeting a SharePoint portal—especially to take over or gain unauthorized access—typically has to navigate a sequence of steps and exploit multiple weaknesses in both technical defenses and governance gaps. Let’s break down what an attacker needs to find on the path, and clarify the firewall’s role in this attack chain.
What Does an Attacker Need to Reach or Take Over a SharePoint Portal?
1. Network Accessibility / Exposure
- For cloud-hosted SharePoint (e.g., Microsoft 365):
- The portal is exposed by design to the public internet (e.g., company.sharepoint.com)
- Firewalls don’t block access here; access is governed by identity and platform controls
- For on-prem SharePoint:
- The attacker needs the portal to be internet-facing, often through a reverse proxy, VPN, or open port
- If firewalls are misconfigured (e.g., port 443 exposed without IP allow-listing or GeoIP restrictions), the attacker gets in
Firewall doesn’t block login in most cloud-based or exposed setups — it’s not an authentication tool.
2. Authentication Weakness or Credential Exposure
- No MFA or MFA can be bypassed (via legacy authentication or phishing)
- Stolen or leaked credentials, harvested via:
- Phishing campaigns
- Dark web dumps (password reuse)
- Credential stuffing from previous breaches
- Service accounts or test users with static passwords still active
3. Privilege Escalation or Admin Access
- Once inside, attacker looks for:
- Overprivileged accounts (e.g., users with admin or site collection rights)
- Misconfigured permission inheritance (guest/external users with edit rights on critical libraries)
- Open sharing links that bypass authentication
- Abandoned sites or “zombie” SharePoint apps that still process requests
4. Governance and Monitoring Gaps
- No alerting for:
- Suspicious login patterns (e.g., new device from unusual geolocation)
- Mass downloads or file sharing
- Creation of new sharing links
- No enforcement of:
- Retention or deletion policies
- Role reviews or periodic access certification
5. Post-Access Exploitation
If the attacker gains contributor or admin access, they may:
- Exfiltrate sensitive documents (financials, IP, HR data)
- Create malicious pages or embed links to launch internal phishing
- Backdoor the site (create hidden accounts, abuse app integrations)
- Move laterally to Microsoft Teams, Outlook, OneDrive using the same identity token
Firewall Limitations in SharePoint Protection
Firewalls Do Not Stop These Attacks If:
- SharePoint Online is used (cloud SaaS = publicly reachable)
- On-premises SharePoint is intentionally published to the web for remote collaboration
- No application-layer filtering (like WAF or reverse proxy hardening) is in place
- MFA and conditional access are not enforced at the identity layer
Firewalls Can Help If:
- Combined with network segmentation, GeoIP filtering, and reverse proxy restrictions
- Used to limit on-prem access to known IPs or via VPN only
- Tied to identity-aware access (e.g., Azure AD Application Proxy with conditional policies)
Final Takeaways
| Step | What Attacker Needs | Can Firewall Stop It? |
| Find portal | Internet-facing URL or IP | ❌ No (esp. for cloud portals) |
| Attempt login | Weak creds or no MFA | ❌ No |
| Privilege escalation | Overprivileged or misconfigured access | ❌ No |
| Abuse access | Lack of monitoring or policies | ❌ No |
| Persist access | No auditing or revocation | ❌ No |
| Identity-based defense (MFA, CA) | Strongest barrier | ✅ Yes (via identity control, not firewall) |
Real Defense = Layered Security:
To protect SharePoint, companies need:
- MFA everywhere
- Conditional access policies
- Permission and sharing reviews
- Data classification and retention
- SIEM-integrated logging
- Governance policies and ownership clarity
Firewalls are only the outer shell — the real protection is identity-driven access and governance maturity.
I’m curious about your risk assessment….. Danny Zeegers
