A TPG Telecom customer died because their Samsung phone couldn’t connect to Triple Zero during a medical emergency. Their phone just didn’t work when they needed it most.
This incident is part of a broader Australian telecommunications crisis that exposed systemic failures in how emergency calling is tested and validated. And here’s the thing that should keep you awake at night: the emergency calling functionality on your company’s mobile devices might have the same problem.
The issue wasn’t new. Samsung phones with firmware preventing emergency calls had been out there for over a year. The firmware locked devices to Vodafone‘s retired 3G network. When users needed to make emergency calls, their phones couldn’t switch networks. The call just failed.
Standard carrier testing didn’t catch it. And now your enterprise mobile device fleet has the same vulnerability.
This article walks through how to verify emergency calling compatibility before you buy handsets, how to implement testing protocols for deployed devices, how to assess vendor risk, and how to build operational resilience into your mobile infrastructure.
What caused the Samsung emergency call failures in Australia?
The firmware in affected Samsung handsets was specifically configured to exclusively use the retired 3G network. When Vodafone’s 3G network shut down and users needed to make emergency calls via Telstra or Optus networks, their phones couldn’t switch. The emergency call failed.
What made this remarkable was the configuration itself. People who understand the technical root causes of VoLTE firmware failures described the firmware setup as “highly irregular” and even “unheard of” in mobile engineering circles. Mobile handsets are supposed to automatically look for alternative mobile service when their home networks are unavailable. This firmware prevented that.
Over 70 Samsung models couldn’t call Triple Zero. Around 60 could be fixed with a software update. The remaining 11 needed replacement.
The issue affected all carriers. While it was discovered on TPG’s network, Telstra’s testing revealed the problem had implications for customers of all mobile operators using affected phones. This wasn’t a carrier-specific configuration. It was a device-level firmware issue that created emergency calling failures across the entire telecommunications system.
TPG doesn’t require suppliers to hardcode handsets to behave in customised ways when interacting with mobile networks, and they didn’t make such a request for these Samsung devices. Why the firmware was configured this way remains unanswered.
Why did carrier testing fail to detect the Samsung firmware issues?
Telstra only discovered the problem after a Vodafone customer reported being unable to make emergency calls on Telstra’s network. A customer report, not testing, triggered the investigation.
Once alerted, Telstra’s engineers tested for nine days. The testing showed phones not connecting to Vodafone’s network when trying to make triple-0 calls, but only when Telstra or Optus networks were unavailable. This was a specific failure scenario that standard carrier certification processes hadn’t been designed to detect.
The testing gap was systemic. TPG had known about emergency calling problems with Samsung handsets since 2024. The VoLTE issue they raised with other carriers was expected to affect only Vodafone users. The firmware problem Telstra later discovered was different—it affected devices across all carriers attempting to switch networks.
Carol Bennett, chief executive of the Australian Communications Consumer Action Network, noted these phones seemed to have slipped through the cracks, and “the blocking of phones should have been done a year ago.”
Telecommunications researcher Dr Gregory pointed out that “the regulator again has left it to the industry and this is one of the problems with the self-regulation approach.”
Following the crisis, ACMA introduced new rules requiring carriers to test how handsets perform when switching networks to place emergency calls. The regulator hand-picked a new testing provider, the National Telecommunications Resilience Centre in Sydney.
The Australian government introduced legislation establishing a Triple Zero custodian with a proactive role in overseeing emergency calling services. Carriers are now required to maintain public registers of network outages.
How do I verify emergency calling compatibility before purchasing handsets?
The carrier testing failures make one thing clear: you need independent verification before deploying devices to your teams.
Start with a pre-procurement device validation program that requires hands-on emergency call testing across all target carriers. Get evaluation units from vendors and test them on your production networks. Don’t make actual emergency calls to Triple Zero or 000—that overwhelms emergency services. Instead, use carrier-provided test numbers that simulate emergency call routing without dispatching emergency responders.
Test across multiple network conditions. Try emergency calls on LTE. Try them with 3G fallback. Test in low signal strength areas. Test under simulated network congestion. Issues that only show up when phones need to switch networks won’t appear in ideal testing conditions.
Document everything. For each test, record the device model, firmware version, carrier, network type, and whether the emergency call succeeded or failed.
Require vendors to provide emergency calling certification documentation and their testing methodology. Don’t just accept a certificate. Ask them to explain their testing process, what scenarios they cover, and how frequently they test.
Include emergency call compatibility as a mandatory requirement in your device procurement RFPs. Make it a pass/fail criterion. If a device doesn’t pass emergency calling tests across all your deployment carriers, it doesn’t go to the next evaluation stage. End of story.
How do I implement emergency call testing in my mobile device fleet?
Once you’ve got devices deployed, you need ongoing verification that emergency calling still works.
Deploy continuous monitoring using your Mobile Device Management system to track device firmware versions across your fleet. When a vendor releases a firmware update, you need to know immediately which devices in your fleet are affected.
Establish a testing schedule. Run quarterly verification of emergency calling functionality on a sample of deployed devices. Before initial deployment, run comprehensive testing on all device models. After each firmware update, test emergency calling before you roll the update out to your entire fleet.
Create a tiered testing approach. New devices get comprehensive pre-deployment testing. Deployed devices get sample-based ongoing verification. Devices used by personnel whose roles require reliable emergency calling—field service technicians, remote workers, employees in high-risk locations—need more frequent testing.
Implement test call protocols using those carrier-provided non-emergency test numbers. Document the procedures: who conducts the tests, how results are recorded, and what the escalation path is if a test fails.
Maintain a small pool of test devices on each carrier for validation testing before fleet-wide updates. When any vendor releases a firmware update, you test it on your test devices first. If emergency calling fails on test devices, you block the update for your entire fleet and escalate to the vendor.
Train your IT staff on emergency calling test procedures and how to identify failures. The testing isn’t complicated, but it needs to be done consistently and documented properly.
Carriers have developed a shared database of handsets with triple zero calling problems, and they’ve pushed for ACMA to publish a register of compliant handsets. Check these resources as part of your ongoing monitoring.
How do I assess vendor risk for mobile device suppliers?
Testing protocols are only as good as the vendors you’re working with. The Optus case study of insourcing network operations from Nokia demonstrates how vendor relationships influence infrastructure reliability.
Develop a vendor qualification framework that evaluates emergency calling testing rigour, firmware quality assurance processes, and incident response capabilities.
Request detailed information on the vendor’s emergency calling test procedures. How frequently do they test? What scenarios do they cover? What happens when a test fails? If a vendor can’t answer these questions with specifics, that’s a red flag.
Review the vendor’s track record. Look at their history of emergency calling issues, firmware defect rates, and response time to fix problems.
Assess the vendor’s development practices. What quality assurance processes do they have for firmware releases? Do they do regression testing? Can they deploy emergency patches quickly?
Evaluate vendor transparency. Are they willing to share test methodologies, defect data, and compliance documentation? Vendors who are defensive about their testing processes are vendors you don’t want to depend on for life-safety functionality.
Include contractual requirements in your procurement agreements. Specify emergency calling warranties, liability provisions for failures, and mandatory notifications when vendors discover emergency calling issues.
Establish vendor performance metrics. Track incident response time, fix deployment speed, and communication quality when issues arise. A vendor whose emergency calling issue response time is measured in weeks instead of days is a vendor you should reconsider.
Create a vendor scorecard that weights emergency calling reliability as a factor in selection decisions. Price matters, but so does the risk of deploying devices that might fail in emergencies.
How do I create an operational resilience plan for mobile infrastructure?
Even with good vendors and testing protocols, you need contingency plans.
Start by identifying which roles and functions in your organisation require guaranteed emergency calling capability. Not every employee faces the same risk, but some roles—field service technicians, remote workers, employees in high-risk locations—need reliable emergency calling more than others.
Develop contingency plans for what happens if mobile emergency calling fails. What are the backup communication methods? Landlines still work. Satellite phones work. Two-way radios work. The specific backup depends on your business context, but the point is to have one.
Implement a multi-carrier strategy. Deploy devices across multiple carriers to reduce single-point-of-failure risk. While the firmware issue affected all carriers, many telecommunications failures are carrier-specific. Having devices on multiple networks means one carrier’s outage doesn’t eliminate your emergency calling capability entirely.
Establish incident response protocols. What do you do when you discover an emergency calling failure in your fleet? Who gets notified? How do you notify affected users? TPG Telecom communicated with customers via SMS and email to urgently update affected devices. You need similar protocols.
Create a communication plan that accounts for how you’ll notify affected users and what escalation paths exist. If you discover a firmware issue that prevents emergency calling, every affected user needs to know immediately.
Document alternative emergency contact methods for personnel in roles where reliable emergency calling is necessary.
Conduct tabletop exercises simulating emergency calling failures. Run through the scenario: a vendor notifies you of an emergency calling firmware issue affecting 30% of your deployed devices. Walk through each step. Where are the gaps?
What broader lessons emerge from the carrier testing failures?
The telecommunications failures that led to this crisis reveal systemic weaknesses in device testing and certification processes.
Don’t rely solely on vendor or carrier testing assurances for any functionality. Carriers tested these devices. The devices received certification. The firmware issue still shipped. Your enterprise testing is the final validation layer.
Implement independent verification for features that must work reliably. Emergency calling is one of those features. Test it yourself under realistic conditions before you deploy devices.
Recognise that standard certification doesn’t guarantee comprehensive testing of all failure scenarios. Certification tests what the certification process is designed to test. Firmware issues can show up in specific scenarios—like network switching during emergency calls—that aren’t part of standard testing protocols.
Understand that competitive and cost pressures lead carriers and vendors to accept lower testing standards than you might assume. Carriers are businesses optimising for different objectives than you are. Their acceptable risk threshold isn’t necessarily your acceptable risk threshold.
Treat firmware updates as changes requiring re-validation of functionality. Every firmware update potentially changes how devices handle emergency calls. Test accordingly.
Build vendor accountability into procurement contracts with specific emergency calling requirements. Make emergency calling reliability a contractual obligation with defined consequences for failures.
Document all testing and maintain an audit trail. Under Australia’s Emergency Service Call Determination, operators must block handsets that can’t complete Triple Zero calls if unpatched for 28-35 days after first warning. If you can demonstrate you’ve tested devices, implemented monitoring, and maintained compliance, you’ve established due diligence for regulatory compliance and liability protection.
The regulatory environment is tightening. Customer safety is the stated priority, as TPG CEO Iñaki Berroeta emphasised following the incident. The subtext is clear: technology leaders are expected to implement reasonable verification procedures to ensure their deployed devices can access emergency services.
FAQ Section
What is VoLTE and how does it affect emergency calling?
VoLTE (Voice over LTE) routes voice calls including emergency calls over 4G/5G data networks instead of older circuit-switched networks. Emergency calls on VoLTE require specific protocol implementations in device firmware, creating compatibility risks if firmware doesn’t properly implement carrier-specific emergency routing procedures.
How many devices were affected by the Samsung emergency call issue?
The firmware issue affected over 70 Samsung Galaxy models deployed across Australian networks including Telstra, Optus, and TPG. While exact numbers weren’t publicly disclosed, the issue impacted thousands of devices, requiring emergency firmware patches across the product range.
What regulations exist for emergency calling on mobile networks in Australia?
ACMA (Australian Communications and Media Authority) enforces the Emergency Service Call Determination requiring carriers to ensure reliable emergency services access. Following the incident, ACMA introduced stricter testing requirements and increased oversight of carrier certification processes for emergency calling functionality.
Can I use carrier-provided test numbers to verify emergency calling without dispatching emergency services?
Yes. Australian carriers provide non-emergency test numbers that simulate emergency call routing and validate device compatibility without dispatching emergency responders. These test numbers should be used for all enterprise emergency calling verification to avoid overwhelming emergency services with test calls.
How does emergency calling differ between 4G and 5G networks?
Both 4G and 5G networks use VoLTE protocols for emergency calling, requiring firmware to implement IP-based emergency call routing instead of circuit-switched protocols used in older 2G/3G networks. 5G introduces additional complexity with network slicing and priority handling that firmware must correctly support.
What should be included in a mobile device procurement checklist for public safety?
Include emergency calling test results across all deployment carriers, vendor emergency calling certification documentation, firmware update testing procedures, incident response capabilities, contractual warranties for emergency calling reliability, vendor track record on emergency calling issues, and compliance with ACMA or equivalent regulatory requirements.
How often should we test emergency calling on company mobile devices?
Implement quarterly sample-based testing of deployed devices, comprehensive testing before initial deployment, and mandatory testing after each firmware update before fleet-wide rollout. Devices used by personnel in roles where reliable emergency calling is necessary should undergo more frequent verification based on risk assessment.
What are technology leaders’ responsibilities for ensuring emergency call functionality?
Technology leaders are responsible for implementing reasonable verification procedures to ensure enterprise-deployed devices can access emergency services. This includes pre-procurement testing, ongoing monitoring, firmware update management, and maintaining documentation demonstrating due diligence for regulatory compliance and liability protection.
Are older Samsung phones safe to use for emergency calls?
Firmware fixes have been deployed addressing the emergency calling issue. Devices running updated firmware should function correctly. Enterprises should verify all devices in their fleet have received emergency calling patches and implement ongoing monitoring to detect any future firmware-related emergency calling issues.
How do firmware updates affect emergency calling on mobile devices?
Firmware updates can introduce emergency calling compatibility issues if updates modify network protocol implementations without adequate testing. Enterprises should treat firmware updates as changes requiring re-validation of emergency calling functionality before deploying updates across device fleets.
What questions should I ask vendors about emergency calling support?
Ask about emergency calling test procedures and frequency, certification processes across carriers, firmware quality assurance practices for emergency protocols, track record of emergency calling defects, incident response procedures for emergency calling failures, warranty coverage for emergency calling functionality, and post-deployment testing requirements for firmware updates.
How can enterprises avoid the Samsung emergency call problem?
Implement independent pre-procurement emergency calling testing, establish vendor risk assessment frameworks prioritising emergency calling reliability, deploy continuous monitoring of firmware versions, test firmware updates before fleet deployment, maintain multi-carrier diversity to reduce single-point-of-failure risk, and include contractual emergency calling requirements in vendor agreements.
