Your Firewall Change Is Now Courtroom Evidence

A routine firewall upgrade at an Australian carrier left about 455 emergency calls unconnected over some 13 hours, and two deaths were linked to it. In July 2026 the national regulator took the carrier to the Federal Court over more than a thousand alleged breaches. The claim is not that the network broke. It is that the obligations around the change were not met. Your change record is now a document written for a court.

Most firewall change processes are built to satisfy an auditor. An auditor asks whether a control existed and whether you followed it. A court asks a harder question: what did you know, when could you have known it, and what did the record show at the time. Those are different documents, and almost nobody is writing the second one.

What actually happened in the change window

At 12:17am on 18 September 2025, the carrier began what it described as a routine firewall upgrade. The general voice network kept working normally throughout. The emergency calling path did not, because it runs over a separate emergency call system, and the change broke that path while leaving everything else intact.

The carrier's own submission to the subsequent Senate inquiry, reported in detail by Information Age, describes a failure that began well before the window opened. At the planning meeting on 8 September, some of the required members of the core network engineering team were not present. During the upgrade itself, staff mistakenly did not redirect Triple Zero traffic off the system before applying a soft lock to the equipment that routes those calls. The plan had a step for it. The step did not happen, and nobody in the room was the person who would have known why it mattered.

Then the monitoring failed to notice, for a reason worth quoting exactly. In the carrier's own words: “Unsuccessful Triple Zero calls were not captured in the data as the calls did not reach the part of the core network from which the records are usually obtained.” The failed calls were invisible because failing removed them from the place the dashboards were looking. Initial testing had shown normal calls connecting, so the change looked clean.

Detection came from outside the organisation. The South Australian Ambulance Service called the carrier three times at around 1:15pm. A major incident was declared internally at 1:51pm. The chief executive and the executive committee were told verbally at 2:51pm, more than fourteen hours after the change began. The first deaths were reported during welfare checks that evening.

The change was verified against the wrong surface

Read that sequence as a change practitioner and the uncomfortable part is how ordinary it is. There was a documented plan. There was a test, and the test passed. There was monitoring, and the monitoring was green. There was a rollback, and it worked as soon as somebody invoked it. The process did not collapse. It ran to completion against a definition of "working" that omitted the only traffic anyone would later go to court over, and the one skipped step was invisible to every check that followed.

A vendor post-mortem of the incident reaches the same boundary, as does the independent Schott Review published in December 2025. Its recommendations are to classify life-critical services and give them stricter change control with time-boxed rollback, to prove changes with end-to-end tests on the actual critical path rather than a representative one, and to monitor success rates on that path instead of aggregate volumes. None of that is exotic. All of it is the difference between testing the firewall and testing what depends on the firewall.

This is the same class of gap as the one behind policy drift, one layer up. Drift detection asks whether the running configuration still matches the approved one. The question here is prior to that: whether the approved one was ever checked against the services that ride on it. A rule set can be perfectly free of drift and still have a dependency nobody mapped.

Then it happened again, and the cause was different

On 11 September 2026, while the court action was already filed, the same carrier lost voice service again. The outage began at about 1:30pm and ran for 76 minutes across four states and territories. Information Age reported that 46 emergency calls were blocked and around 190,000 customers had two call attempts fail to connect. Police carried out 46 welfare checks across three states, and everyone was found safe.

The important part is what the carrier said about the cause. It attributed the outage to an equipment or system fault and has not elaborated, and the regulator's investigation into it remains open, so nobody outside the company can yet say whether a change was involved. What is documented is that this time the problem was identified through network monitoring within minutes rather than through a phone call from the police thirteen hours later. The service failed anyway.

That pairing is the actual lesson, and it cuts against the comfortable reading of the first incident. Fixing the observability of a critical path is necessary and it is not sufficient, because observability tells you that the path has failed, not that the path exists. The two incidents share a dependency and nothing else.

Dimension	September 2025	September 2026
Trigger	Planned firewall upgrade	Attributed to an equipment or system fault
Duration	About 13 hours	76 minutes
Emergency calls affected	605 attempted, about 455 failed	46
How it was detected	Customer and police contact	Network monitoring, within minutes
Was the critical path monitored?	No, emergency calls were excluded	Yes
Outcome	Two linked deaths, regulatory action	No reported harm

What the regulator is actually alleging

On 30 July 2026 the Australian Communications and Media Authority commenced Federal Court proceedings over the 2025 outage, alleging more than a thousand contraventions of two obligations: ensuring customers making emergency calls had access to the emergency call service, and ensuring those calls were carried. The maximum penalty is A$250,000 per contravention. Reported estimates of the total exposure vary between outlets, so the figure worth holding is the per-contravention maximum and the count, not any single headline sum.

The regulator's chair put the standard plainly in the ACMA release on the court action: "Australians rightly expect that when they call Triple Zero, their call will connect. The circumstances of this outage meant that did not reliably occur, leaving people unable to connect to potentially life-saving services." There is no mention of a firewall in that sentence, and that is the point. The obligation is defined on the outcome, so the technical cause is only relevant as the mechanism by which the outcome was missed.

The carrier had a prior emergency-calling failure in November 2023 that drew a penalty of more than A$12 million. A repeat, after a prior enforcement outcome, is the pattern that moves a matter from a fine to litigation. In regulated European sectors the equivalent machinery already exists. The evidence obligations under NIS2 and the operational-resilience testing requirements in DORA both run on the same logic: demonstrate the control worked, on the service that matters, at the time it mattered.

What this changes in a firewall change process

Nothing in the recommendations below is new methodology. Each is an existing control applied to a surface most change processes leave out, which is the set of services that depend on the rules being changed.

• Name the life-critical flows in the change record. Not the zones and not the rule IDs, the services. A change ticket that lists source, destination and port does not tell a reviewer in two years' time that emergency call signalling traversed that path.
• Test the dependent service, not the device. A successful commit and a passing interface check prove the firewall is healthy. An end-to-end transaction on the critical path proves the thing the obligation is written about.
• Verify that monitoring can see a failure, not just measure a success. The 2025 failure was invisible because failed emergency calls never reached the part of the network the records come from. Counting what arrives will never show you what stopped arriving, and that distinction is invisible on a dashboard that is green either way.
• Check who is actually in the planning meeting. The people who know which services ride on a path are the ones who can name the step that must not be skipped. Their absence from a planning session is a change risk, and it is one of the few that is trivially visible in advance.
• Time-box the rollback decision. The rollback in 2025 worked. It was invoked after 13 hours because no one had committed in advance to a point at which the window closes regardless of whether the cause is understood. This is the same discipline as an emergency change that expires and reverts itself, applied to planned work.
• Write the record for a reader who was not there. Who approved, on what evidence, against which test result, with what known exclusions. Contemporaneous notes are the only part of this that cannot be reconstructed afterwards.

The staging and verification discipline is the same one that firmware faults now demand, and the coverage question is the one that failover testing is supposed to answer and usually answers only for the paths somebody remembered to include. A recertification cycle that reviews rules without reviewing what depends on them has the same blind spot in slow motion.

Why it matters

The firewall change in question was almost certainly approved by a competent team following a documented process. That is not a mitigating detail, it is the finding. A change process that verifies the device and not the dependency will pass every audit it faces and still produce a record that reads badly in a court, because the two readers are asking different questions.

The shift worth internalising is that a change record has stopped being an internal artefact. Regulators in telecoms, finance and critical infrastructure are converging on obligations defined by service outcome, which makes the contemporaneous evidence of what you tested and what you knew into the substance of the defence. For a full treatment of the underlying discipline, the complete guide to firewall change management covers the process itself. This post is about who reads it afterwards.

Would your change records show which dependent services were tested before the window opened? The free NIS2 Readiness Check walks through the evidence a firewall change process has to produce.