By the time a risk is obvious to everyone in a room, it's usually already been a risk for a while. Obvious is late. The people who actually understand a system, a contract, or a process can typically see a problem taking shape long before it's loud enough for everyone else to notice from the outside.

That gap, between when a real risk starts and when it becomes visible to a non-specialist, is exactly where the damage happens. Waiting for the visible version of a problem before acting on it isn't caution, it's just later.

A good partner isn't the one who reacts fastest once something's on fire. It's the one who was already watching, who flagged the issue before it needed flagging urgently, and who already had a plan in place before you needed one.

That's a genuinely different skill from incident response. It's not about being fast when things go wrong. It's about noticing quietly, consistently, before things go wrong, and being trusted enough that "this needs attention" is taken seriously the first time it's said, not the third.

Here's the part worth sitting with: nothing about the vulnerability changed between January and March. The danger was exactly as real in January as it was in March. The only thing that changed was that by March, it was finally visible enough to make headlines.

Acting on it in January meant taking it seriously before it looked dangerous. Acting on it in March meant taking it seriously once everyone else already had to.

This pattern isn't specific to SharePoint, or to security. It shows up anywhere risk quietly builds before it's acknowledged: a contract clause nobody double-checked, a permission structure that's grown looser over years, a process that's one departure away from breaking. In every case, the actual danger and the visible danger arrive at different times, and the gap between them is where a good partner earns their keep.

The standard worth holding any technology or security partner to isn't "how quickly do you respond when something breaks." It's "what have you already flagged that hasn't broken yet."

Want a partner who's watching before things get loud? Get in touch and we'll show you what we're already keeping an eye on.

Passkeys replace a code you type with a credential tied to your device or biometric, like a fingerprint, face scan, or security key. There's no code to intercept, no number to SIM-swap, and nothing that can be phished over a call or text.

This is what "phishing-resistant authentication" actually means in practice: the credential itself can't be tricked out of a user, because there's nothing to hand over.

Every user still on SMS or voice MFA needs to move to a phishing-resistant method, and Microsoft recommends passkeys, before Microsoft-provided SMS and voice retire on 1 February 2027. Acting before 1 September 2026 means your organisation controls the rollout. Waiting means Entra ID controls it for you, one blocking prompt at a time.

CISA confirmed that four separate SharePoint vulnerabilities are being actively exploited in the wild, not just one. That matters because CVEs are sometimes discovered and patched quietly, well before attackers pick them up. Having four confirmed under active exploitation at once, in the same year, signals a much more concentrated wave of attacker interest in SharePoint specifically.

These aren't new bugs introduced by a recent update. They sit in subsystems that have been part of SharePoint since 2016, and they affect every version built on that foundation, including the latest Subscription Edition. AI-assisted vulnerability research is a big part of why these older, previously overlooked issues are surfacing now: it's simply become faster to fuzz code and find these combinations of bugs.

Beyond the initial breach, attackers behind these exploits have been stealing IIS machine keys and using them to deploy malware that persists inside the same service that serves your SharePoint environment to your users. In practice, that means malicious code can live in a trusted location and be pushed out to your users directly, potentially harvesting credentials that grant access to completely separate systems beyond SharePoint itself.

SharePoint Online is not affected by these vulnerabilities. Microsoft has already patched the online service. This issue is specific to SharePoint on-premise deployments, including SharePoint 2016, 2019, and Subscription Edition. If you're running a version older than 2013, you're already dealing with a separate set of unpatched, unsupported risks.

Log in to your SharePoint service and confirm which version and build you're currently running. Then check your Windows Update history for the relevant security KB:

●  SharePoint Subscription Edition: KB5002873

●  SharePoint 2019: KB5002874

●  SharePoint 2016: KB5002880

Microsoft's Security Update Guide also lets you search by CVE number to see exactly which patch resolves which vulnerability for your version.

Microsoft released security updates for SharePoint 2016 and 2019 on 14 July 2026 that address these vulnerabilities, even though both versions are officially out of support. Patch immediately using the KB references above. Once patched, start planning your upgrade path, since these platforms won't receive fixes indefinitely.

Beyond patching, review whether your SharePoint environment needs to be publicly accessible at all. If it doesn't need to be reachable from anywhere on the internet, put it behind a VPN. Reducing unnecessary exposure shrinks your attack surface regardless of how quickly you can patch.

If you want help reviewing your current email security configuration against these specific vectors, get in touch and we can help.

Microsoft has disclosed a new spoofing vulnerability affecting SharePoint Enterprise Server 2016, 2019, and Subscription Edition. CISA added it to their Known Exploited Vulnerabilities catalogue the same day the patch was released, and ordered US federal agencies to patch by 28 April 2026.

As of this week, researchers have identified 1,370 SharePoint servers still publicly exposed and unpatched, more than a week after Microsoft released the fix.

And as Kyle pointed out in our conversation, that number is almost certainly understated.

The previous vulnerability was a Remote Code Execution flaw, which means an attacker could run any code they wanted on the system. Last week's vulnerability is described as a spoofing vulnerability, which sounds less alarming, but is worth understanding properly.

It is tempting to look at 1,370 unpatched servers and assume those organisations are simply not paying attention. The reality is more nuanced.

For organisations running large or complex SharePoint environments, applying a patch is not a single click. It often involves a structured release process: testing the patch in a staging environment, validating that it does not break existing integrations, and pushing it through a formal change management board for approval. In heavily regulated industries, that approval chain alone can take weeks.

This is the question we asked Kyle directly, and his answer is one every business leader should sit with for a moment. SharePoint is not a particularly insecure platform. It sits behind multiple layers of defence and integrates tightly with Active Directory and Microsoft Entra ID.

What has changed is that SharePoint has become a far more valuable target. Since SharePoint 2016, the platform has matured significantly, and many of the largest organisations in the world now run mission-critical environments on it. Larger, more valuable deployments mean attackers have a stronger commercial incentive to invest time in finding ways in.

There is also a second factor: artificial intelligence. AI tools are helping attackers analyse code paths and chain together small, individually low-severity vulnerabilities into something far more dangerous.

In other words, you cannot only worry about the headline-grabbing CVEs. The medium-severity ones matter too, because attackers are increasingly stitching them together.

SharePoint Server 2016 reaches end of extended support on 14 July 2026. After that date, Microsoft will no longer issue security patches for SharePoint 2016. Whatever vulnerabilities exist in the code, including ones not yet discovered, will remain there permanently.

If you are running SharePoint 2016 and you have not yet started a migration conversation, this is the signal to start. The migration path is not a single jump. Organisations on 2016 cannot move directly to SharePoint Subscription Edition. They need to upgrade to 2019 first, then to Subscription Edition, or rebuild the environment and migrate the data across using a migration tool.

Both options take time. Three months out from the deadline, that time is now the constraint.

If you are not sure whether your SharePoint environment is patched, exposed, or ready for the July 2026 deadline, our team can help you find out. We offer SharePoint security assessments, vulnerability scans, penetration testing, patch verification, and full migration planning for SharePoint 2016 environments.

Reach out to us and we will walk through your environment with you. 

In July 2025, Microsoft disclosed a critical vulnerability known as ToolShell (CVE-2025-53770), rated 9.8 out of 10 on the severity scale (where 10 is the most dangerous possible). This vulnerability affected all supported versions of SharePoint On-Premises: SharePoint Server 2016, 2019, and Subscription Edition.

What made this particularly alarming was that attackers didn't need a password or any prior access to your system. If they could reach your SharePoint server, they could get in.

Before Microsoft could fully patch the issue, more than 400 organisations globally had already been compromised, including US government agencies. Chinese state-sponsored threat actors were among those identified, alongside ransomware groups who exploited the same vulnerability for financial gain.

That was 2025. In 2026, the attacks have continued.

SharePoint is not just a file storage system. For many organisations, it is the central nervous system of the business, holding sensitive documents, running workflows, storing employee data, and connecting to other Microsoft services like Teams, Outlook, and OneDrive.

When an attacker gets into SharePoint, they don't just see your files. They can:

•  Move laterally across your entire Microsoft environment

•  Access sensitive business and personal data

•  Install backdoors that persist even after patches are applied

•  Deploy ransomware across your network

•  Steal credentials and impersonate trusted users

And here is the part that should concern every business leader most: you may not know it has happened. These attacks are designed to be quiet. By the time you notice something is wrong, the attacker may have been inside your systems for weeks or months.

If you answered yes to the first question and no to any of the others, your organisation is carrying unnecessary risk.

This is not a moment for a committee to review and report back in 30 days. The following actions need to be on your IT team's desk this week:

We are not here to tell every organisation to move to the cloud. There are legitimate reasons (regulatory requirements, data sovereignty, legacy integrations) why some organisations must keep SharePoint On-Premises.

But the security overhead is real and growing. Every critical vulnerability that Microsoft patches in the cloud automatically means nothing to an on-premises customer who hasn't applied the update. The responsibility sits squarely with your IT team, and the window between disclosure and exploitation is shrinking.

And then there is the end-of-life reality. SharePoint Server 2016 and SharePoint Server 2019 both reach end of support on 14 July 2026, just 90 days from now. After that date, Microsoft will release no further security patches for either version. Any vulnerability discovered after July 2026 will remain permanently unpatched on those platforms. If you are running SharePoint Server Subscription Edition, you are not affected by this deadline — it remains supported with no fixed end date. But if you are on 2016 or 2019, the options are clear: migrate to SharePoint Online, upgrade to SharePoint Server Subscription Edition, or accept an ever-growing security exposure with no vendor safety net.

If you are running On-Premises purely out of habit, inertia, or because it has always been that way: the clock is no longer just ticking. It has nearly run out.

Looking across the common failure patterns, there's a single theme: legacy script patterns that nobody had revisited in years. The solutions that broke were rarely recently built, they were older integrations, older web parts, scripts embedded when SharePoint was configured years ago and then forgotten.

CSP enforcement didn't create new problems; it surfaced old ones. That's actually the point. The report-only window from late 2025 through 28 February was designed exactly for this: a chance to audit before enforcement hit. Teams that used that window had nothing to worry about on 1 March. Teams that didn't are doing triage now.

When Microsoft announced SharePoint Online's Content Security Policy enforcement in early 2026, they included a lifeline for organisations that needed more time: a Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true flag that pushed enforcement from 1 March to 1 June 2026. If your IT team enabled that flag, you bought yourself 90 days.

Those 90 days are now running out.

The purpose of the delay was to give organisations time to audit their environments, fix non-compliant scripts, and test changes, not to skip preparation entirely. If you haven't started yet, this post is your starting gun.

The pattern we've seen with 1 March enforcement is that the teams who struggled were the ones who started late. Trusted Script Source changes can take up to 24 hours to propagate across a tenant. If you're making changes on 30 May and something doesn't propagate in time, you have no margin for error.

Eight weeks sounds like plenty of time. In practice, the audit usually surfaces more than expected, vendor responses take longer than expected, and internal sign-off processes take time. Start now.

If your SharePoint environment includes solutions from third-party vendors, analytics tools, chatbots, form builders, or similar, those vendors may need to update their products to be CSP-compliant. Reach out to them with the specific violation URLs from your Purview audit and ask for a compliance timeline.

In the meantime, you can temporarily register their script sources as trusted, but the long-term fix needs to come from their end if their solutions use inline scripting patterns.

There's a version of this conversation that happens after an incident. After a breach. After data has been exfiltrated, or systems have been locked down by ransomware, or a client calls asking why their data appeared somewhere it shouldn't.

That conversation is expensive. Remediation is expensive. Reputational damage is expensive. Regulatory exposure (especially under POPIA) can be very expensive.

A penetration test, run proactively, finds the same problems before they become incidents. It's the difference between fixing a lock and explaining to your clients why their data is gone.

We've seen it go both ways. Businesses that test regularly catch things early and fix them quietly. Businesses that don't, often find out the hard way — and at the worst possible time.