Telstra NTP Outage — 8 July 2026

1. Intent of this brief

This brief has been prepared primarily to highlight the technology governance, risk-management and operationalcontrol failures that allowed a routine maintenance activity to escalate into a major service outage.

It also seeks to reinforce the importance of effective technology governance and risk control in reducing the likelihood and impact of such events. In particular, it illustrates the complexity of modern technology environments, the speed at which failures can spread, and how a seemingly minor or overlooked component can cause widespread disruption if it is not managed with the appropriate oversight, controls and resilience. These lessons are especially relevant to the banking and financial services sector, where technology underpins critical services, customer transactions and regulatory obligations.

While the brief includes the relevant background, technical sequence of events and resulting impact, it is not intended to provide an exhaustive forensic account of the incident. Its purpose is to draw attention to the importance of disciplined patch governance, accurate configuration management, robust maintenance assurance and resilient architecture, and to encourage organizations to consider whether similar control weaknesses may exist within their own technology environments.

For further information, queries, corrections, or feedback, email consult.traicenta@traicenta.com.

2. Executive Summary

On 8 July 2026, Telstra suffered a nationwide mobile-network outage after a Network Time Protocol (NTP) server restarted with its internal date set approximately 20 years in the past. The incorrect date propagated into parts of the mobile network, disrupting certificate validation, authentication and other services dependent on accurate time.

The incident was not caused by a cyberattack or an inherently unforeseeable technical event.

2.1. Incident at a glance

Date: Wednesday, 8 July 2026. Issue start time: 4:20 a.m. Issue end time: ~4:00 p.m. Organization:

• Telstra is Australia’s largest telecommunications company and operates the country’s largest mobile network, reaching approximately 99.7% of the Australian population. Duration:
• The issue was detected at approximately 4:20 a.m.
• Most mobile calls and data services were restored by around 10:00 a.m.
• The initial network issue was addressed by approximately 4:00 p.m., around 12 hours after detection.
• A separate but related Triple Zero issue continued until 10:38 a.m. on 9 July. Scale of impact:
• Telstra has not published a definitive number of individual customers who lost service.
• Approximately 45% of all mobile calls and data sessions were affected at the peak.
• Telstra subsequently notified approximately 8.8 million customers and businesses, but it has not confirmed that all of them experienced disruption. Services affected:
• Mobile voice calls, mobile data sessions and Triple Zero emergency calls.
• Payment and transport services dependent on Telstra mobile connectivity.

3. Root Cause

3.1. Immediate technical root cause

• Following maintenance and a restart, a GPS timing card in Telstra’s Melbourne NTP server supplied an incorrect date - approximately 20 years in the past, in 2006.
• That incorrect time was then accepted and propagated through parts of the mobile network, causing certificates and time-dependent authentication processes to fail.

3.2. Underlying root cause

The underlying root cause, however, was a combination of control failures:

• a relevant software or firmware update had not been applied;
• a previous material design change affecting the server’s time-source behavior had not been properly documented;
• maintenance procedures therefore did not reflect the actual production configuration;
• the restarted server was able to resume an authoritative role without adequate validation; and
• the architecture did not adequately prevent an implausible time value from being accepted and distributed into systems dependent on certificates, authentication and network synchronization.

4. Lessons learned

The Telstra outage has direct relevance for banks, insurers, payment companies, fintechs and capital-markets institutions. BFSI environments depend heavily on accurate time, trusted configuration, controlled maintenance and resilient architecture. Weaknesses in any of these areas can affect customer transactions, digital channels, payment processing, fraud controls, regulatory reporting and financial-market operations.

4.1. Patch governance beyond cybersecurity vulnerabilities

For BFSI organizations, patch governance must extend beyond cybersecurity vulnerabilities.

Firmware, middleware and infrastructure updates may address reliability, timing, interoperability or dataintegrity defects that can create systemic operational risk even where no malicious threat is involved (Appendix A, #1).

These components often operate for long periods without interruption and may be excluded from standard patching cycles because they are considered stable, difficult to restart or operationally sensitive. This can create a false sense of security. Stability may simply mean that a latent defect has not yet been triggered.

Institutions should maintain a single, risk-based process for vendor advisories covering security, resilience, functional and firmware updates. (Appendix A, #2).

Patch exceptions should not remain open indefinitely. They should be reviewed whenever there is a change in architecture, transaction volumes, regulatory criticality, vendor support status or dependency on the affected component.

For example, an update originally considered non-essential may become critical if a device is later promoted from a secondary role to an authoritative role, connected to more systems or incorporated into a critical payment path.

Boards and executive risk committees need to look beyond headline patch-compliance percentages. A bank can report 98% patch compliance while the remaining 2% contains the systems capable of causing the greatest disruption.

The objective should be the closure of material risk, not simply achievement of a numerical patching target.

4.2. Configuration Management

BFSI environments are highly interconnected and often contain decades of accumulated technology. Core banking systems, payment platforms, digital channels, fraud engines, treasury systems, data platforms and security services may depend on configurations that are not fully reflected in current documentation.

The Telstra incident illustrates how a change made to solve an earlier problem can create a hidden dependency years later (Appendix A, #3).

Configuration management must therefore be more than maintaining a Configuration Management Database. It needs to establish an accurate and controlled representation of the production environment covering areas like logical and physical architecture, application and infrastructure dependencies, authoritative sources of data and control, software and firmware versions, network routes and security rules, failover and recovery behavior, etc.

This is especially important for systems that underpin regulatory obligations, such as payments, sanctions screening, anti-money-laundering monitoring, customer authentication, transaction recording and financial reporting.

An undocumented configuration change creates risks where none existed prior such as maintenance personnel following obsolete procedures, disaster-recovery environments may not match production, audit and compliance functions may relying on inaccurate control descriptions, recovery testing may have validated a configuration that no longer exists.

Organizations should require emergency changes to be formally reconciled after the immediate incident has been resolved. This should include updates to architecture documents, operating procedures, CMDB records, test cases, recovery plans and risk assessments.

A useful management test is: Can the organization demonstrate that its approved documentation accurately reflects how each critical service is configured and how it will behave after restart, failover or recovery?

Where this cannot be demonstrated, the institution is carrying hidden operational and regulatory risk.

4.3. Maintenance Assurance

Maintenance in banking and financial services frequently takes place within narrow windows and under pressure to restore service before the next business day, payment cut-off, market opening or regulatory processing deadline which may encourage teams to focus on completing the technical task rather than assuring the end-to-end service outcome.

The Telstra outage shows why successful completion of a maintenance activity does not necessarily mean successful restoration of the service. The physical work may be completed correctly while the restart exposes dormant defects, outdated firmware, invalid configuration or dependency failures.

Maintenance assurance should cover the complete lifecycle of the change (Appendix A, #4, #5, #6).

Critical or authoritative systems should not immediately regain full production authority after maintenance. A staged return-to-service process should be used where possible, with independent validation before traffic, transactions or control functions are fully restored.

Particular caution is required for systems that have operated continuously for long periods. A system may appear reliable because it has not recently been rebooted and can reveal resident defects (Appendix A, #7).

Organizations should therefore include controlled reboot and power-restoration scenarios in operational-resilience testing, rather than discovering restart behavior during production maintenance.

4.4. Architectural Resilience

The most salient lesson this incident provides is that redundancy is not resilience.

Traditional high-availability designs typically assume that a component will fail by becoming unavailable. They therefore use secondary servers, network paths, data centers or service providers to maintain continuity.

The Telstra incident illustrates a more dangerous failure mode: a component remains available and authoritative but supplies incorrect information.

This type of integrity failure is highly relevant to BFSI ((Appendix A, #8) and, in such cases, conventional failover may not help because the system appears healthy from an availability perspective.

A resilient architecture should therefore be designed to address three distinct conditions:

• Availability failure - the service is unavailable.
• Integrity failure - the service is available but provides incorrect or corrupted information.
• Control failure - the service behaves correctly at a technical level but outside approved policy or authority. For foundational services such as time synchronization, resilient controls are mandatory (Appendix A, #9) and the same principles should be applied to other critical services.

For example, payment or pricing platforms should not accept a material change from a single source without validation. Identity platforms should detect anomalous changes in authentication behavior. Fraud and AI systems should be monitored for unexpected shifts in decisions, not only for system availability.

Architectural resilience should also consider common-mode failure. Multiple servers do not provide genuine diversity if they share:

• the same vendor;
• the same firmware defect;
• the same data source;
• the same network route;
• the same power supply;
• the same cloud region;
• the same administrator credentials; or
• the same configuration error. Institutions should therefore test whether their redundant components are truly independent or merely duplicated (Appendix A, #10).

For regulated financial institutions, architectural resilience must also support the protection of customer interests, market integrity and regulatory obligations. A system that remains online while processing incorrect transactions may create greater harm than a system that stops safely.

4.5. Overall Takeaway

These four areas should not be treated as separate technology-control disciplines.

• weak patch governance allows known defects to remain unresolved;
• weak configuration management obscures how the production environment actually operates;
• weak maintenance assurance permits systems to be returned to service without adequate validation;
• weak architectural resilience allows incorrect behavior to spread before it can be contained; and
• the understanding that redundancy does not necessarily mean resilience. Together, these weaknesses can turn a routine infrastructure intervention into a major operationalresilience event affecting customers, payments, regulatory compliance and market confidence.

The principal lesson for regulated financial organizations is: Critical services must be governed not only for availability, but also for integrity, recoverability and safe failure. The objective is not merely to keep systems running - it is to ensure they continue operating correctly, within approved controls, and without causing harm to customers or the financial system.

5. What Happened

5.1. The initiating event

At 11:51 p.m. on 7 July, a technician arrived at Telstra’s Exhibition Street facility in Melbourne to undertake planned maintenance, including replacement of the chassis housing an NTP server. The work was required because a backup power feed within the chassis had developed a fault.

Maintenance was completed at approximately 3:38 a.m. on 8 July, after which the server was restarted.

The affected equipment was an approximately 15-year-old SSU 2000 timing system. Telstra operated three geographically separated NTP servers across Melbourne, Sydney and Perth.

5.2. Why the equipment had to be powered down

The maintenance involved replacement of the chassis housing the server, rather than simply replacing a hot-swappable power-supply module.

In a modern dual-power configuration, an individual power supply can often be replaced while the remaining supply keeps the device operational. A chassis replacement is more intrusive: internal cards and components must generally be transferred or reinstalled, requiring the equipment to be taken offline and cold-started.

The shutdown itself did not appear to cause the national outage. Telstra’s other timing servers continued supporting the network while the Melbourne device was unavailable. The systemic failure began when the maintained device was restarted with an incorrect date and returned to service as a trusted source.

This distinction is important:

• redundancy protected against the server being absent;
• it did not adequately protect against the server being available but wrong.

5.3. The clock rollback

When the Melbourne server restarted, a GPS timing card within the equipment supplied an incorrect date, causing the system clock to move back to 2006.

The behaviour was consistent with GPS week-number rollover. Legacy GPS implementations can represent the week number using a limited counter that repeats after 1,024 weeks - approximately 19.7 years. Without appropriate firmware or an accurate reference epoch, a receiver can interpret the current week as belonging to the previous cycle and calculate a date nearly 20 years in the past.

GPS rollover is therefore not an unknown or unprecedented failure mode. It is a recognized risk affecting legacy or incorrectly updated GPS-dependent equipment.

Telstra’s final external technical investigation findings had not been published as of the date of this brief. The precise interaction between the GPS card, the undocumented configuration and the NTP hierarchy therefore remains subject to confirmation.

5.4. The cascade

The affected server distributed the incorrect date to other systems in Telstra’s mobile environment. As downstream systems accepted the false time, services dependent on accurate and consistent clocks began to fail.

Accurate time underpins:

• digital-certificate validation;
• network and user authentication;
• security-token validity;
• transaction and event sequencing;
• system logging and forensic reconstruction;
• database consistency;
• distributed application coordination; and
• telecommunications signaling and session management. Digital certificates contain defined validity periods. A system believing that the year was 2006 could treat certificates issued in the 2020s as not yet valid. Authentication sessions and security tokens could also be rejected where communicating systems disagreed materially about the current time.

This produced a cascading failure: systems remained operational at a component level but stopped trusting or communicating with one another.

The incident illustrates why a corrupted timing source can be more dangerous than an unavailable one. An unavailable source can be detected and bypassed; a source confidently publishing incorrect information may be accepted until failures begin appearing across otherwise unrelated systems.

5.5. Timeline

6. Why It Happened

Three immediate control failures turned a routine maintenance task into a national incident.

6.1. A known software update was not applied

The GPS timing card had not received a relevant software or firmware update. Telstra told the Senate inquiry that it had been advised of the update in 2022 and reminded again in January 2026. Telstra acknowledged that applying the update might have prevented the outage.

The issue was not simply that a patch was missed. The organization lacked an effective mechanism to ensure that the outstanding risk was:

• assigned to an accountable owner;
• assessed against the server’s actual configuration;
• implemented within an appropriate timeframe;
• formally accepted when deferred; or
• escalated until closed.

6.2. A material design change was not documented

An intentional design change had previously been made to address an earlier equipment fault. The change affected how the server obtained and asserted authoritative time after restart.

It was not properly reflected in Telstra’s configuration records or maintenance procedures. As a result, the maintenance team did not have a complete understanding of how the equipment would behave following a cold restart.

The maintenance personnel may therefore have followed the approved procedure correctly however the procedure itself was based on incomplete information.

6.3. Incorrect time was not contained

Telstra had multiple NTP servers, but redundancy alone did not prevent the outage.

The architecture appears to have lacked sufficient controls to prevent or rapidly quarantine:

• a clock adjustment of approximately 20 years;
• material disagreement between timing sources;
• an anomalous source returning from maintenance;
• a GPS-derived date inconsistent with independent references; or
• the propagation of an extreme time shift to dependent systems. The precise controls in place have not been publicly disclosed. However, the outcome shows that the environment was better able to withstand loss of a timing source than corruption of a timing source.

7. Key Failures

7.1. Critical-asset identification failure

The affected server was a relatively modest infrastructure component, but it provided a foundational service to a national mobile network. Its criticality appears not to have been governed in proportion to its dependency footprint and potential blast radius. Asset criticality should reflect not only replacement cost, hardware complexity, transaction volume or customer visibility, but also how many systems rely on the asset and what happens if it provides incorrect information.

7.2. Patch-governance failure

A relevant vendor update remained outstanding despite repeated notifications. There was no sufficiently effective closed-loop process linking vendor alerts, technical assessment, risk acceptance, remediation deadlines and executive escalation. A patch exception should never remain open indefinitely merely because a device appears stable in day-to-day operation.

7.3. Configuration-management failure

A material design change was not incorporated into configuration records, architecture documentation, maintenance procedures, recovery instructions, patch assessments or resilience testing. The organization therefore maintained two versions of reality: the documented configuration and the configuration actually operating in production.

7.4. Change-risk assessment failure

The maintenance appears to have been approached primarily as replacement of a faulty chassis and power component. The risk assessment did not adequately account for what a cold restart might expose in equipment that had operated for a prolonged period, including dormant firmware defects, loss of retained state, GPS reacquisition behavior, reversion to unexpected configuration, certificate implications or changes in the device’s authority within the NTP hierarchy.

7.5. Architectural resilience failure

The availability of three timing servers created redundancy, but not necessarily resilience. True resilience requires systems to determine whether a source is trustworthy - not simply whether it is reachable. The architecture should have been capable of challenging a source that suddenly disagreed with other trusted references by nearly 20 years.

7.6. Monitoring and anomaly-detection failure

An extreme clock shift should be treated as a high-severity integrity event. Controls should ordinarily prevent large time adjustments from being accepted automatically and should trigger immediate investigation when sources disagree, time moves backwards, drift exceeds an approved threshold, a source changes stratum or authority, GPS reference data conflicts with independent sources, or certificate failures begin appearing across multiple platforms.

7.7. Legacy-technology governance failure

The server was approximately 15 years old. Age alone does not make equipment unsafe, particularly where it remains vendor-supported. However, ageing infrastructure accumulates operational risk through undocumented interventions, limited restart history, unavailable institutional knowledge, deferred updates, unusual dependencies, hardware constraints and assumptions that have not recently been tested. “Supported” is not the same as “resilient.”

7.8. Restart and recovery-testing failure

Equipment that operates continuously for years may appear reliable because the failure mode is dormant until reboot. Critical infrastructure should be tested through controlled cold restarts, powerloss scenarios, GPS signal reacquisition, restoration from prolonged shutdown, failover and failback, source-corruption scenarios and return-to-service validation.

7.9. Risk-integration failure

The relevant facts were distributed across infrastructure, vendor management, architecture, security, operations and continuity teams. No effective end-to-end control brought those facts together and converted them into a single, visible operational risk.

7.10. Risk-closure failure

The ultimate governance failure was the inability to convert known or discoverable risk into closed risk. The patch remained open, the design change remained undocumented, the restart scenario remained inadequately tested, and the integrity risk remained insufficiently controlled. Telstra’s CEO accepted that the company’s controls were not good enough and that the organization was accountable for the outcome.

8. Impact

Media reports linked the telecommunications outage to disruption of train services and payment systems. It should not, however, be assumed from the available evidence that railway signaling clocks themselves failed or that every reported downstream disruption was directly caused by NTP propagation. Some impacts may simply have resulted from the loss of Telstra mobile connectivity.

9. Time as Critical Infrastructure

Time services are often treated as background utilities: stable, inexpensive and rarely examined unless they stop responding. That assumption is dangerous.

Modern enterprises depend on trusted time for security, operations and accountability. A timing failure can affect systems that otherwise have no obvious relationship to one another, creating simultaneous symptoms across networks, applications, databases, security services and physical operations (Appendix A, #11).

For AI and edge-computing environments, time is also important for distributed inference, event ordering, model and data-version alignment, sensor fusion, orchestration, access-token validation and coordination between geographically distributed nodes.

As systems become more distributed, automated and time-sensitive, the integrity of their clock sources becomes more - not less - important.

10. Established Timing-Resilience Guidance

The Telstra incident did not occur in the absence of relevant industry guidance.

10.1. CISA: Time Guidance for Network Operators, CIOs and CISOs

CISA’s guidance treats time as an enterprise risk that should be actively managed. It recommends understanding timing dependencies, monitoring timing infrastructure, testing resilience and avoiding unexamined dependence on a single external source.

10.2. DHS: Resilient PNT Conformance Framework

The US Department of Homeland Security framework describes expected resilience behaviours for equipment that relies on positioning, navigation and timing. Its principles include:

• detecting anomalous or manipulated PNT inputs;
• maintaining service through holdover capability;
• using alternative or diverse sources;
• transitioning safely between sources;
• reporting degraded confidence; and
• recovering predictably following disruption.

10.3. NIST: Foundational PNT Profile

NIST’s PNT Profile maps PNT risk into the NIST Cybersecurity Framework. It supports organizations in governing PNT risk, identifying systems dependent on PNT, selecting appropriate timing sources, protecting PNT equipment and data, detecting disruption or manipulation, and responding to and recovering from PNT incidents. These US publications are not, by themselves, mandatory requirements for Telstra. They are nevertheless useful, widely applicable reference points for organizations seeking to implement good timing-resilience practices.

Their common message is straightforward: use diverse sources, maintain holdover capability, monitor continuously, validate before trusting, and govern time as a critical dependency.

11. Regulatory and Governance Response

The Australian Communications and Media Authority (ACMA) began engaging with Telstra and other stakeholders during the incident, including in Telstra’s capacity as the Emergency Call Person for Triple Zero.

The outage is being examined against Australian telecommunications obligations governing emergencycall availability and customer communications during significant outages.

The Senate Environment and Communications References Committee also examined the incident as part of its inquiry into network outages and Triple Zero service failures.

Telstra commissioned an external expert review to validate the preliminary root cause and examine:

• why the design change was not documented;
• why the software update was not implemented;
• whether maintenance and change controls were adequate;
• why the incorrect date was able to propagate; and
• what changes are required to prevent recurrence. At the date of this brief, the external review and regulatory investigation had not published final findings. Conclusions about specific legal breaches or penalties would therefore be premature.

12. Implications for Your Organization

12.1. Identify your authoritative time services

Three servers are not truly diverse if all three share the same defect, vendor dependency or GPS reference.

• which systems provide authoritative time;
• where those systems obtain their own reference;
• which applications and platforms depend on them;
• whether all sources ultimately depend on the same GPS constellation, vendor or firmware;
• who owns the end-to-end service; and
• what the potential blast radius would be if time became unavailable or incorrect.

12.2. Govern timing as a service, not an appliance

A formal timing-service owner should govern the end-to-end service rather than merely maintaining individual NTP devices.

• architecture;
• source diversity;
• security;
• patching;
• configuration;
• monitoring;
• testing;
• incident response; and
• lifecycle replacement.

12.3. Validate before accepting time

Controls should prevent a timing source from automatically making extreme adjustments.

• source voting or quorum;
• comparison against independent references;
• maximum step-change thresholds;
• gradual clock slewing;
• rejection of backward time movement;
• manual approval for extreme changes;
• quarantine after restart;
• confidence scoring; and
• staged restoration to authoritative status.

12.4. Implement source diversity

Diversity must be assessed across technology, vendor, location, software, communications path and underlying reference source.

• geographically separated GPS or GNSS receivers;
• terrestrial timing services;
• independent NTP providers;
• precision time protocol sources;
• atomic or high-stability local clocks;
• trusted network-delivered time; and
• independent out-of-band validation.

12.5. Establish robust holdover capability

If an external reference becomes unavailable or untrustworthy, critical systems should be able to maintain sufficiently accurate local time for a defined period.

• required timing accuracy;
• acceptable drift;
• expected holdover duration;
• which services can continue in degraded mode; and
• when operations must be restricted or stopped.

12.6. Strengthen patch and vulnerability governance

Patch assessments must be repeated whenever system usage or architecture changes.

• centrally recorded;
• assigned to accountable owners;
• assessed against actual configurations;
• prioritised by operational impact;
• implemented within defined timeframes;
• formally accepted when deferred; and
• escalated when overdue.

12.7. Reconcile temporary and emergency changes

There is nothing so permanent as a temporary operational fix.

• architecture diagrams;
• configuration baselines;
• asset records;
• maintenance procedures;
• test cases;
• monitoring;
• recovery plans; and
• risk registers.

12.8. Test bad data, not only unavailable systems

Integrity failures frequently spread further than simple outages because downstream systems continue trusting the source.

• incorrect time;
• corrupted DNS responses;
• invalid identity information;
• erroneous configuration;
• stale reference data; or
• misleading health status.

12.9. Require controlled return to service

After maintenance, a critical source should not immediately regain full authority.

• software and firmware versions;
• active configuration;
• reference-source status;
• clock accuracy;
• agreement with independent sources;
• certificate behavior;
• downstream health; and
• absence of abnormal drift.

12.10. Include timing failures in crisis exercises

Timing compromise should be included in operational-resilience and cyber exercises.

• GPS week-number rollover;
• GPS jamming or spoofing;
• malicious NTP manipulation;
• loss of all external references;
• disagreement among trusted sources;
• excessive clock drift;
• certificate failures caused by time changes; and
• corrupted timestamps affecting audit evidence.

13. What Telstra Has Said

Telstra accepted accountability for the incident and acknowledged that maintenance should not have been capable of causing disruption on this scale.

Chief Executive Vicki Brady told the Senate inquiry that Telstra’s controls had not been good enough and that the company’s review would examine why the design change was not documented, why the software update was not completed and how known risks should be captured, prioritized and closed before they affect customers.

14. Bottom Line

This appears to have been a preventable outage.

The maintenance activity exposed the weakness, but it did not create all the conditions that caused the incident. Those conditions had accumulated over time:

a known update remained outstanding; an earlier design intervention was not documented; maintenance instructions no longer reflected production reality; cold-start behavior had not been sufficiently validated; redundancy did not adequately address integrity failure; and a highly privileged infrastructure service was able to distribute an implausible date without being stopped. The fundamental failure was not simply that an NTP server reset to the wrong year. It was the failure to ensure that an incorrect clock could not become a trusted source of truth.

Operational resilience is not achieved through redundancy alone. It requires diverse and independently validated sources, strong holdover capability, disciplined patch and configuration governance, continuous anomaly detection, controlled restoration and explicit ownership of time as critical infrastructure.

15. Selected Public Sources

Telstra submission and CEO opening statement to the Senate inquiry into Triple Zero service outages. Australian Senate Environment and Communications References Committee proceedings. Australian Communications and Media Authority statement and investigation material. ABC News reporting on Telstra’s Senate evidence and the affected SSU 2000 timing server. Reuters, The Guardian and iTnews reporting on the outage, certificate failures, the missed update and undocumented design change. CISA, Time Guidance for Network Operators, CIOs and CISOs. US Department of Homeland Security, Resilient PNT Conformance Framework. NIST IR 8323 Rev. 2, Foundational PNT Profile.

This brief reflects publicly available information as of 1 August 2026. Telstra’s external investigation and relevant regulatory reviews remain in progress. Some technical conclusions may be refined when final findings are published.

Appendix A

1) A bank may have mature monthly operating-system patching but still carry significant exposure in less visible components such as:

• network time appliances;
• payment switches;
• hardware security modules;
• storage controllers;
• mainframe peripherals;
• ATM and point-of-sale infrastructure;
• database appliances;
• telecommunications equipment;
• building-management systems; and
• security and monitoring platforms.

2) Each material advisory should have:

• an accountable business and technology owner;
• an impact assessment based on actual configuration and usage;
• a defined remediation date;
• documented compensating controls where implementation is delayed;
• formal risk acceptance by an appropriate authority; and
• escalation where the agreed date is exceeded.

3) In a bank, similar risks can arise from:

• emergency routing changes made during an outage;
• temporary firewall rules that are never removed;
• database parameters altered to resolve performance issues;
• changes to certificate-validation behavior;
• manual overrides in payment or fraud systems;
• undocumented batch-processing dependencies;
• failover settings introduced during disaster-recovery testing;
• changes to privileged access or authentication flows; and
• temporary integrations that become permanent.

4) Before maintenance, teams should confirm:

• the current production configuration;
• all upstream and downstream dependencies;
• firmware and software levels;
• certificate and license validity;
• vendor advisories and known defects;
• rollback feasibility;
• expected restart and failover behavior;
• business-service impact;
• regulatory and customer communication requirements; and
• whether the maintenance window allows sufficient validation.

5) During maintenance, organizations should ensure:

• clear command and control;
• segregation of implementation and validation responsibilities;
• real-time monitoring of critical business services;
• predefined stop and rollback criteria;
• preservation of audit evidence; and
• escalation where observed behavior differs from the approved plan.

6) After maintenance, validation should extend beyond confirming that the device or application is running. It should test whether the business service is operating correctly. For BFSI environments, this may include:

• customer login and multifactor authentication;
• account balance and transaction enquiries;
• payment initiation and settlement;
• ATM and card authorisation;
• fraud and sanctions screening;
• message-queue processing;
• batch and end-of-day processing;
• database replication;
• digital-certificate validation;
• audit logging and timestamp accuracy;
• interfaces with regulators, clearing houses and external counterparties; and failover readiness.

7) Cold restart can reveal:

• firmware defects;
• expired certificates;
• lost configuration state;
• failed dependencies;
• corrupted startup files;
• unsupported hardware behavior;
• time-synchronization errors; or
• differences between documented and actual recovery procedures.

8) Examples include:

• an NTP server distributing incorrect time;
• a reference-data feed publishing incorrect exchange rates;
• an identity service authenticating the wrong user;
• a fraud engine applying an incorrect rule set;
• a sanctions list failing to update;
• a pricing engine producing erroneous valuations;
• a configuration platform distributing a faulty setting;
• an AI model producing systematically misleading decisions;
• a payment switch duplicating or misrouting messages; or
• a database replica serving stale information.

9) Resilient controls may include:

• multiple genuinely independent sources;
• source voting or quorum mechanisms;
• comparison against trusted external references;
• limits on permitted time adjustments;
• rejection of backward or implausible time changes;
• quarantine of a source following restart;
• confidence scoring;
• gradual reintroduction into production;
• strong local holdover capability; and
• immediate alerts where authoritative sources disagree.

10) A useful resilience assessment should ask:

• Can the service continue if a component is unavailable?
• Can the organization detect if a component is functioning incorrectly?
• Can the incorrect source be isolated before it affects customers or transactions?
• Is there an independent way to verify the accuracy of the service?
• Can operations continue safely in a degraded mode?
• How long can the service operate without its primary external dependency?
• Will recovery procedures prevent the failed component from immediately regaining authority?

11) For banks and other regulated organizations, inaccurate time can affect:

• payment and transaction sequencing;
• fraud monitoring;
• cryptographic key and certificate validity;
• authentication tokens;
• database replication;
• trading and market timestamps;
• sanctions and transaction-monitoring records;
• audit trails;
• incident reconstruction;
• backup consistency; and
• legal or regulatory evidence.