Microsoft Outage; N-able N-central Taken Offline After Multiple Vulnerability Disclosures; ConnectWise ScreenConnect Breaches Under Investigation

I just finished a presentation on digital sovereignty: the idea that we need to understand which critical functions depend on providers outside our control, and what we can do when those dependencies fail. Organizations should use the lack of access to Microsoft 365 services as an opportunity to record what stopped working, which workarounds people used, and what they couldn't do at all. Then they should ask whether their continuity plans assumed Microsoft's services would always be available. Reviewing those answers will show where alternatives and mitigation strategies are worth the investment.

Microsoft has not yet shared the root cause of the outage, and I imagine they are still investigating. Recovering from any outage like this can be complex, and what we are likely seeing is that as Microsoft began resolving the issue, resources coming back online were insufficient to cover the load, causing additional outages and problems. It is often difficult to carefully ramp up incoming connections after an extended outage. This is even more difficult as email delays have caused additional mail volume due to “delay warnings” that mail servers send when an email cannot be delivered for some time.

This is not the first time we have experienced a major outage with a cloud service provider, and it won't be the last. Organisations that have outsourced services to cloud providers need to reassess their risk profile. In particular, they need to develop cyber resilience plans to ensure they can continue to provide a minimum viable level of service to their customers. This is not only good cybersecurity practice, but it also makes good business sense. Organisations subject to regulations such as the EU NIS2 Directive, DORA, the Cyber Resilience Act, and GDPR should also understand their specific resilience and incident reporting obligations under those regulations, and ensure they have appropriate plans and reporting mechanisms in place.

This is one for lessons learned. We all breathe a little easier with M365 services returning. The root cause remains unclear, lots of finger pointing and arm-chair quarterbacking isn't helping. While many of us are still reeling from the outage, and others are crowing for not being on the MS platform, it's still time to gather lessons learned. The proximity to patch Tuesday gives credence to a side effect of patching their systems over a cyberattack. MS claims this is not an attack. I feel for the MS teams working to restore services fully. There is no such thing as 100% uptime or risk-free patching. We can stack the deck in our favor — heck, how many of us selected multi-cloud deployments (GCP, Azure and/or AWS) for services which need 5-9’s availability? Remember that was expensive too. The hard part is not throwing the baby out with the bath water when something still breaks. Revisit your SLAs and requirements for office productivity and email, as you may find they are not what you thought. Make sure you’re up on all the latest tips and techniques for having your desired performance and uptime. Have you considered tenant backup options? Plan any adjustments carefully. Remember any third-party office productivity provider has the same risks; transitions are impactful.

I have worked a lot of outages and done a lot of root cause analysis in my career, and it's a bit disturbing seeing one of the world's largest software companies and email providers publicly struggling to figure out what the problem is. Since software engineers and other technical roles have started using AI, we've seen five nines fly out the window. GitHub even lost all its nines a few months ago, dropping below 90% uptime. AWS and Google also had major outages that were traced to AI-related mistakes. Though this has become a clear trend, we have no evidence that this outage is related to AI or vibe-coding. With that said, the inevitable post mortem coming out of this incident will be a must-read.

"A large number of servers unexpectedly unavailable" is certainly one way to frame an outage. With government agencies impacted, federal inquiries are practically guaranteed. Microsoft can get ahead of the fallout by offering full transparency on the root cause. Meanwhile, affected organizations face a secondary risk: employees turning to personal email to keep business moving and potentially exposing proprietary data in the process.

Taking N-central offline was a bold but necessary step in this case. For users with on-premises installs, however, this alert may have come too late. As so often, the right thing to do is to assume compromise and carefully review affected systems. Patches are now available, and N-able was pretty quick to publish them.

Johannes makes an important point about the difficult but necessary decision to take N-central offline. What concerns me is the enormous reach of remote management platforms. If attackers compromise the management infrastructure, they may gain access to the many systems it administers. With additional exploit chains emerging even after the initial hotfix, organizations need to validate their actual exposure and examine managed endpoints for signs of compromise. Here's an incident response scenario worth rehearsing: How do you investigate and recover when the very tools you normally use to manage your systems can no longer be trusted?

Having had to make this decision a few times during my career, I can say from firsthand experience that taking a critical service offline is never easy, particularly when customers depend upon it. However, there are times when temporarily suspending a service may be the most responsible course of action while serious incidents are investigated and addressed. Therefore, if your organisation gives someone the responsibility for making such decisions, you must also ensure they have the authority, autonomy, and management support to make them. In the heat of an incident, it is essential that those making difficult decisions — in line with established procedures and based on the information available at the time — can be confident that management will stand by them, even when those decisions have significant consequences.

The more troubling part of this story is the source of the chaos: a researcher that works as a penetration tester and holds many cybersecurity certifications, including a CISSP. Most folks in cybersecurity understand that businesses have to balance priorities and cybersecurity isn’t always the top concern. Some, however, see security as a binary situation — if a vulnerability is found, it must be fixed. In this particular case, the researcher had a bad experience reporting vulnerabilities to N-able earlier this year and felt ignored, as they still have not been fixed. He used AI to find dozens more vulnerabilities and went the full disclosure route. He may feel like he’s punishing the vendor, but all the vendor’s customers are also impacted. The vendor blames the researcher for “non-responsible communication,” but in the researcher’s eyes, the vendor is the one shirking its responsibilities.

Interesting finger-pointing and disclosure response/non-response stories around this one. N-Central is a service which lets you manage and monitor networks and devices from a central location, so flaws which permit RCE, create default administrator accounts, and grant root privileges kind of matter. Regardless, if you're on the hosted service, it's updated to 2026.4 HF2. You need to get your local install updated if you're self-hosted. Then be ready for an added hotfix to cover the last few issues. Consider that if your local instance needs to be exposed to the Internet, it's going to be poked at, patched or otherwise.

Guidance to pull systems offline isn't issued lightly, and it underscores just how severe these vulnerabilities are. Any organization running the N-able platform, whether cloud or self-hosted, needs to review this advisory and patch immediately.

There's an important architectural lesson in this attack. We can invest heavily in securing a remote management platform, complete with strong authentication and carefully controlled permissions, only to introduce a third-party extension that provides another path to those same powerful capabilities. If an extension can execute administrative commands, it deserves the same security scrutiny as the platform itself. Organizations need to understand what their management extensions can do, how they're authenticated, and whether they bypass established controls. And when responding to an incident involving these tools, make sure you have independent ways to investigate and recover. Otherwise, the very system you're using to clean up an intrusion might help spread it!

Besides making you're searching for the IoCs, make sure that you're looking for unexpected remote support clients, and that your EDR is set for full monitoring/blocking mode and its logs are getting to the SIEM. Speaking of that, have you got alerts for when there are few or no logs from monitored systems? You don't want false positives or false negatives. Remember the cliché — it's quiet… too quiet — we all know how that movie turns out.

There's a troubling lesson here about the use of custom code during critical security operations. An HSM key ceremony is supposed to be among the most carefully controlled processes in our industry, yet a one-off Python script used to bridge two vendors undermined the security assurances the ceremony was designed to provide. When we're dealing with foundational cryptographic trust, even seemingly minor workarounds deserve extraordinary scrutiny. Migration procedures need to be reviewed, tested, and independently validated, including the security of the resulting key material and how it was handled throughout the process. A ceremony that completes successfully isn't necessarily a ceremony that produced secure keys.

Don’t panic. We started trusting these certificates as they were distributed via updates, and trust will be removed with subsequent updates. The question you have to ask is, do you want to move the revoked root certificates to an untrusted certificate store, which you would have to orchestrate as well? That is the most complete solution, but assess the risks and returns before heading down that path.

The security of our online world depends heavily on the trust we place in certificate authorities and the processes they use to protect their cryptographic keys. When those processes fail, the consequences can extend far beyond the organisation involved. Organisations should remember that security is not simply about using strong encryption or certified hardware. The people, processes, and software used to manage cryptographic keys are just as important. Strong encryption is of little value if the keys protecting it are not properly secured.

The AI-enhanced vulnerability discovery continues; 1,200 is too many to individually analyze. Leverage every trick you can, both from knowing which systems can automatically update, and from information from sources like the ISC, KEV and KrebsOnSecurity to see what’s significant for those cases where you’re doing regression testing. With as much as we're patching automatically, make sure you know how to roll back where things go awry. Many of us are still reeling from this week’s MS Outlook outage, and now is the time to gather lessons learned.

An old metric for deciding if software was ready to release was the number of tester hours required to find the next defect. First generation dynamic/static software testing tools shifted that metric, but fuzzing and AI-based vulnerability discovery tools have blown up the equations. In both cases, good guy and “friendly crowd” use of those tools in advance of production greatly reduces risk.

Another heavy month for Microsoft vulnerabilities; a trend that has become the new normal over the last six months. With the sheer volume of critical flaws, manual remediation is no longer sustainable, and waiting for a CVE to hit the CISA KEV catalog is a losing game. If you run Microsoft products, patch immediately and prioritize automating your deployment pipeline.

You’re getting the KEV update emails from CISA directly, right? You want to be in a position of knowing what is and is not applicable for proactive response rather than scrambling to find out what you may have missed. Hint: If you read this summary and choked in surprise, you need to refine your processes.

CISA's push toward a three-day mitigation window for high-risk KEV entries is a step in the right direction, but AI-driven exploit automation easily outpaces that timeline. The real test for the executive branch is whether FCEB agencies can actually sustain this high-tempo operating model.

One of the great lessons from decades of collaborative threat intelligence, including the SANS Internet Storm Center, is that individual observations become far more valuable when we can correlate them. I like that CISA is incorporating MITRE ATT&CK terminology into its incident reporting process, potentially making it easier to recognize relationships among attacks that initially appear unrelated. The real test will be how effectively that information gets translated into timely, actionable intelligence for defenders. Organizations are more likely to contribute useful reports when they can see that the information is helping others protect themselves. Let's make sure this becomes a productive exchange of intelligence rather than simply another reporting obligation.

A standardized and updated reporting form, particularly one tied to ATT&CK, will help leverage the information from incidents, allowing for better cross-correlation and analysis. Where you're collecting data like this, be sure to have a review process to ensure you're collecting the right data and leveraging the current applicable models or frameworks. Playing catchup is hard enough without being dismissed for lack of relevance. CISA's update addresses both of those.

Good one to use to make sure that (B) the security team is involved ideally in all Merger and Acquisition phases, but as a minimum in reviewing/approving onboarding and connectivity; AFTER (A), assuring the security team has the staff, skills, tools, and processes to support decision-maker timelines.

Incorporating systems from a merger or acquisition is tricky and needs to be done meticulously. Beware of delaying updates to put these on an equivalent security posture or postpone access and permission reviews, to include disabling access for those who no longer need it. Watch for convenience-based access control options.

This incident underscores two critical lessons for M&A: First, due diligence must include a rigorous technical review of cybersecurity practices; and second, teams need an immediate plan to replace legacy systems or mitigate their risks. Organizations should make both non-negotiable in any current or future acquisitions.