N-able N-central Alert: The Question to Ask Your MSP

There is a line in the alert ASD’s Australian Cyber Security Centre published today that most people will skim past. It says the alert “is intended for a technical audience”. A few lines on: “Small to medium business should engage with their MSP or Enterprise IT provider to understand if they use the N-able N-central product.”

Read those two together and the problem is obvious. A national cyber agency has handed every small and medium business in the country an action item, in a document written for somebody else. Most owners will not know what to ask, what a good answer sounds like, or what to do if the answer is vague.

So here is the question, here is a good answer, and here is what your ability to get one tells you about your supplier controls.

Facts in this article are current as at 19 August 2026, the date of the alert, with a further update added on 26 August 2026 covering a second N-able product. Patch status changes. The governance point does not.

Miniature network operations room with staff at monitoring screens and an incident list on a whiteboard, and a server rack room beyond glass with one cabinet door standing open — ASD’s ACSC rates both N-central authentication bypass flaws at 8.2. Patches were released on 1 August 2026, then Hotfix 2 followed on 6 August, so an organisation that patched in between was patched and still exposed.

What the alert says

ASD’s ACSC has issued a HIGH alert, marked “Act quickly”, stating it is aware of active exploitation in Australia using vulnerabilities affecting N-able N-central. Organisations using the product should assess their exposure and apply the vendor’s mitigations as a priority.

Two vulnerabilities are named, CVE-2026-18556 and CVE-2026-18577, both scored 8.2 and rated HIGH. Both are authentication bypass flaws that, in the ACSC’s words, “may allow unauthorised access through an alternate path or channel”. In plainer terms, a way in that does not involve knowing anyone’s password. They affect all current versions of N-central, including 2026.3.

One point of fairness before going further. ASD’s ACSC states that it “has no information to indicate that a specific industry or sector is being targeted”, and it names no affected organisation. Nothing here should be read as suggesting otherwise.

Why this matters more than the average CVE

N-central is a remote monitoring and management platform, an RMM, used by managed service providers and larger internal IT teams to “discover, manage, automate, and secure endpoints and network infrastructure”. That is a polite way of describing something with extraordinary reach: an RMM installs software on your staff laptops, pushes configuration changes and runs scripts across the estate without anyone at your end approving each action. Privileged access to everything is the job.

So a flaw that lets someone past authentication on one is not a single server’s problem. It is potentially every endpoint that server manages, at once, through a channel your people are trained to trust. That is the shape of risk we described when ASD asked critical infrastructure operators to isolate from their suppliers. It arrives through a connection you deliberately opened and then stopped thinking about.

The five days that make the point

The ACSC says patches were released on 1 August 2026, then that Hotfix 2 was released on 6 August 2026, and that organisations should upgrade to Hotfix 2 as a priority.

Sit with that. An organisation could have patched on 2 August, told its clients truthfully that it had patched, closed the ticket, and still been exposed on 5 August. Nobody lied. The process worked as designed. The answer was still wrong.

That is the whole argument for treating controls as continuing rather than completed. A control is not a control because it was applied once. It is a control when you can evidence it is currently effective. Here the fix itself moved, so anyone whose assurance stopped at “applied” was carrying a risk they believed they had closed. Same point as the APRA action against Bendigo and Adelaide Bank, where a penetration test in 2020 had already found what the regulator found in 2026.

A second N-able flaw, and this one is the password vault

Update, 26 August 2026. Days after the alert above, a separate flaw was disclosed in N-able Passportal, the company’s cloud credential management product. Passportal is what many managed service providers use to store their clients’ passwords.

The flaw sat in the browser extension. It allowed any site a user visited, or any iframe on that site, to gain persistent access to the decrypted vault for up to 100 days. N-able patched it within three days, and both the researcher and the SANS editorial board described the vendor’s handling as a model of responsible disclosure.

That last point is not a throwaway. This is not a story about a careless vendor. The disclosure worked, the fix was fast, and the response was better than the industry average. The uncomfortable part sits underneath it.

Two products from one supplier inside a fortnight: the platform that reaches your endpoints, and the vault that holds your credentials. Most businesses using an external IT provider could not name either product, let alone say which version is running or when a browser extension was last updated. That is the gap, and it is a governance gap rather than a technical one.

So there is a third question worth adding to the two below: does anyone hold our credentials in a shared vault, which product is it, and when was the browser extension last updated? Credential managers are a sensible control, not a mistake. They are also, as one SANS editor put it, a skeleton key. A control that deliberately concentrates risk is still the right control, and it earns a higher standard of assurance than one that does not. Where the data itself is caught up in it, the notification obligation still lands with you.

The question to ask, and what a good answer sounds like

If you do not run your own IT, this is the message to send today. Keep it short.

Do you use N-able N-central in delivering our services? If so, are you on Hotfix 2, released 6 August 2026, and when did you apply it? Have you reviewed your logs for indicators of compromise using the vendor’s detection scripts, and is the management interface reachable from the internet?

A good answer is specific and dated. It sounds like: “Yes, we run N-central. We applied the 1 August patch on the 2nd and Hotfix 2 on the 7th. The interface is not internet-facing, it sits behind our VPN. We ran the vendor IoC scripts on the 7th and again this morning, and found nothing. Here is the change record.”

A yes or no on the product. A version. Dates. The exposure of the interface. Evidence that someone went looking for compromise rather than assuming patching settled it. And the record offered without being asked twice. A good answer can also be “no, we use something else, and here is what we do when an alert like this lands”. The second half is the part that matters.

What a vague answer tells you

The answers to worry about sound reassuring and contain nothing. “We’re across it.” “Our systems are fully patched.” “We take security very seriously.” None of those say whether the product is in use, what version is running, or whether anyone looked for signs of intrusion.

If you cannot get a specific answer within a business day to a HIGH alert naming a product your provider may run, you have learned something. Not that they are careless, and not that you are exposed. You have learned that you have no mechanism for getting an answer, which is a finding in its own right. The day you need one urgently is not the day to start building it.

Ask the second question while you have their attention: if this had been a real compromise rather than a patching exercise, would you have told us, on what timeframe, and in writing? Most IT agreements are detailed about response times and monthly fees, and silent on notification after a security incident. That is rarely bad faith. Usually nobody asked.

If you run N-central yourself

For MSPs and internal IT teams, the alert’s own mitigation advice is the checklist:

Review your networks for vulnerable versions of N-central.
Upgrade to Hotfix 2 as a priority, and apply patches as soon as practicable.
Review whether the interface needs to be internet-facing at all. Management planes are the last thing that should be publicly reachable, and this is the cheapest control on the list.
Monitor for suspicious activity using the vendor’s indicator of compromise detection scripts. Patching prevents the next intrusion. It does nothing about one that already happened.
If a third party manages the product for you, confirm with them that it is patched and monitored.
Notify ASD’s ACSC if you detect suspicious activity, on 1300 CYBER1 (1300 292 371). Victims should report through ReportCyber.

If you are an MSP there is a client-facing job here too. A short, specific, dated note sent before clients ask is worth a great deal, and it is the same evidence you will want in your own file later.

Outsourcing the work does not move the obligation

This is the part that survives the patch cycle.

Using a third party to run your IT does not transfer your obligations under Australian Privacy Principle 11. You are expected to take reasonable steps to protect the personal information you hold, and where a provider handles it for you, managing that provider is one of those steps. We set out what the OAIC expects in securing personal information under APP 11. If your data is exposed through your provider’s platform, the notification is yours to make.

The same logic showed up when the ACSC warned about mass exploitation of website content management systems and many businesses answered “our web agency looks after that”. Possibly. But do you know that, or do you assume it?

Where this sits in ISO 27001

ISO/IEC 27001:2022 has a run of Annex A controls aimed squarely at this. A.5.19 requires processes to manage the security risks of using suppliers’ products or services. A.5.20 requires the relevant requirements to be agreed with each supplier, which is where the notification timeframe and the patching obligation belong. A.5.21 covers the ICT supply chain, which is what an RMM platform is. And A.5.22 is the one most organisations skip: monitor, review and manage change in supplier service delivery on an ongoing basis, rather than at onboarding and never again.

Alongside those, A.8.8, management of technical vulnerabilities, requires you to obtain information about vulnerabilities in the systems you use, evaluate your exposure and act. Note the first word. Obtaining the information is part of the control, so subscribing to the ACSC alerts and giving somebody the job of reading them is the standard, not diligence beyond it. A.8.16, monitoring activities, turns “we patched” into “we watched”.

None of that needs a certificate to be worth doing. What certification adds is that these become things somebody owns, with dates, that an auditor will ask to see. A system built that way answers today’s alert in an afternoon. Without one, you start from “who do we even ask?”

If your controls are less mature, the Essential Eight is the sensible first step, and patching applications is one of its eight strategies. Note the ceiling: it will tell you to patch. It will not tell you how to hold a supplier to it.

What to do this week

Send the question, with a deadline, to whoever runs your endpoints.
Write the answer down in whatever passes for your supplier register, with the date. Not in an inbox.
Check who holds privileged access to your environment, including tools and service accounts, not just people. Most access reviews only list humans, which is the gap we wrote about here.
Check whether your agreements say anything about patching timeframes and breach notification. If not, add it at renewal.
Decide who reads the ACSC alerts. If the answer is nobody, that is today’s real finding.

None of that requires a security team. It requires somebody to own it.

Frequently asked questions

Our provider said they are patched. Is that enough?

Ask which patch. Patches were released on 1 August and Hotfix 2 followed on 6 August, so “patched” on its own does not tell you whether the current fix is applied. A version and a date does.

If they were compromised, would that be our data breach?

It could be. If personal information you are responsible for was accessed and serious harm is likely, the Notifiable Data Breaches scheme is engaged and the notification is yours to make. It is also why insurers now ask these questions directly, which we covered in cyber insurance and CPS 230.

Speak with an experienced ISO 27001 auditor

The technical work belongs to whoever runs your endpoints. The governance question is the one worth fixing permanently: whether you can get a specific, dated, evidenced answer out of a supplier when it matters.

Streamline is led by a practising ISO Lead Auditor, so you get the view from the other side of the audit table. We build ISO 27001 management systems that put supplier controls, vulnerability management and monitoring on somebody’s desk with a due date, we provide the independent internal audit your system needs under clause 9.2, and we offer cyber and information security advisory for organisations not heading to certification yet.

For most small and medium Australian organisations, ISO 27001 certification takes three to six months and a first-year investment of roughly $15,000 to $30,000. Built as part of an integrated management system alongside quality, safety or environmental, the cost per standard runs at about 50 to 75 per cent of standalone.

Send the question today. If the answer comes back vague, get in touch and we will help you build the mechanism that gets you a better one.

Brisbane 07 3667 8280
Sydney 02 8315 7780
Melbourne 03 9034 3990

Source: ASD’s ACSC, “Active exploitation of remote monitoring and management platform within Australia”, high alert, 19 August 2026, including the CVE details, affected versions and the full mitigation guidance. Report through ReportCyber, or call 1300 CYBER1 (1300 292 371).

This article is general information from an auditing and management system perspective. It is not technical remediation advice and it is not legal advice. Patch guidance changes, so confirm current status with the vendor and with ASD’s ACSC.

General guidance only. This article is general information, not legal, financial, safety or compliance advice, and it does not take account of your specific circumstances. Streamline ISO Consultants are ISO management-system consultants, not lawyers or licensed advisers. Standards, laws and regulator guidance change, and details were correct only at the time of writing. Always seek professional advice before acting. See our full Disclaimer.