Summary

  • The Australian Communications and Media Authority, or ACMA, found that Optus was the gaining carriage service provider for 44 Coles Mobile ports between 23 September and 23 October 2024 and proceeded without completing one of the permitted additional identity-verification processes.
  • ACMA later said scammers exploited a vulnerability in a third-party verification system, gained control of at least four consumers' mobile services, accessed bank accounts and caused reported aggregate losses of AUD 39,000. Those figures must not be inflated into 44 known victims or 44 separate financial losses.
  • A port updates where a unique number is served and who can receive its calls and messages. The transfer record is necessary, but it is only a ledger entry: it cannot prove that the requester had the right to make the transfer when the verification path itself was bypassed.

What a mobile-number port actually changes

Keeping a phone number when moving to another provider feels simple from the customer's side. A person chooses a new service, asks to retain the existing number and waits for the old service to stop and the new one to begin. The number looks unchanged on the phone screen. Underneath that continuity, several networks and records have changed.

A mobile number is a unique public numbering resource used to direct calls and messages to one active service context. Porting does not merely copy the digits into a new billing profile. It changes the network responsibility for serving that number. Routing information must point traffic toward the gaining provider. The losing provider must release the number through the agreed process. Customer and service records must remain coherent enough for the change to complete without creating two active destinations or leaving the number unreachable.

The most important practical consequence is control. Whoever controls the newly activated service can receive calls and text messages intended for that number. Many organisations use possession of a phone as one signal in login recovery, transaction confirmation or fraud detection. A transferred number can therefore become a bridge into services far beyond telecommunications.

This does not mean the digits are personal property in the ordinary sense. The Australian standard uses more careful language: the customer is the “rights of use holder” for the mobile service number. That phrase matters. It recognises a legally and operationally governed right to use a unique number without confusing the right with ownership of the national numbering resource itself.

Before a port begins, the gaining provider needs evidence that the requester is that rights-of-use holder or an authorised representative. It also needs evidence that the requester has direct and immediate access to a device associated with the service. Those tests address two different risks. A person might know account information but not control the existing device. Another person might briefly possess a device but lack authority to transfer the service. A secure process needs a permitted verification path that satisfies the rule, not a collection of reassuring-looking fields.

The roles in a port are easier to understand than the acronyms

The “gaining provider” is the provider to which the number is moving. The “losing provider” is the provider currently serving it. In this investigation, ACMA identified Optus as the gaining carriage service provider for the Coles Mobile brand for the 44 investigated ports.

The gaining provider is important because it initiates the change that will give its service control of the number. It cannot treat acceptance by the downstream porting workflow as proof that the requester was authorised. The identity gate comes before the transfer is initiated. If that gate is missing, bypassed or falsely marked complete, later systems can faithfully execute the wrong instruction.

The losing provider also has duties under the broader porting framework, and shared systems carry the transfer between providers. But a multi-party workflow does not erase the responsibility attached to a specific control. ACMA's finding in this matter focused on the gaining provider's failure to use the required additional identity-verification process and its decision to proceed without that process.

Coles Mobile is relevant as the customer-facing brand in the event, while Optus was the carriage service provider identified in the findings. A reader does not need to know the commercial structure behind every retail mobile brand to understand the accountability point. When a provider supplies or arranges the public mobile service and acts as the gaining provider, a branded sales channel or an outsourced verification component does not make the regulated handoff somebody else's problem.

What ACMA found about the 44 ports

The regulator's final findings are short and unusually specific. The relevant period ran from 23 September to 23 October 2024. ACMA found 44 contraventions of subsection 8(2) of the Telecommunications (Mobile Number Pre-Porting Additional Identity Verification) Industry Standard 2020. It also found 44 contraventions of subsection 8(5), with consequent contraventions of subsection 128(1) of the Telecommunications Act 1997.

Subsection 8(2) is about using a permitted additional identity-verification process to confirm the requester has the necessary authority. Subsection 8(5) is the fail-closed rule: a provider must not proceed with the port if the required process has not been used. Together they establish both a positive duty to verify and a negative duty to stop when verification has not succeeded.

ACMA said Optus did not complete any of the relevant identity-verification processes for the 44 numbers ported through its online form in the period. The report also says a unique verification code was sent by SMS to each of those numbers. That combination is instructive. A code can be transmitted while the complete control still fails. The existence of a message, a generated code or a populated status field does not establish that the approved end-to-end process proved the right thing.

Parts of the report are redacted because publishing technical vulnerability details could create security risk. That is an important evidence boundary. The public material supports the conclusion that a system deficiency allowed the verification process to be bypassed. It does not support an instructional account of the exploit, the identity of the third-party service or a claim about every internal component involved.

ACMA's public announcement adds the consumer consequence. It says scammers exploited a vulnerability in a third-party identity-verification system used by Optus. The weakness enabled them to bypass part of the process, gain control of at least four consumers' mobile services and access bank accounts. Reported losses totalled AUD 39,000.

The different numbers describe different things. Forty-four is the number of investigated ports for which ACMA found the required verification process was not completed and the port nevertheless proceeded. “At least four” is the published minimum number of consumer mobile services the regulator said scammers controlled. AUD 39,000 is the reported aggregate financial loss identified in the announcement. It would be inaccurate to turn those figures into 44 people who each lost money, or to assume the aggregate amount captures every financial and non-financial effect.

A verification code is an event, not a conclusion

Many digital systems treat a one-time code as a compact answer to a difficult question. The system sends a code, the user returns a code and a green status appears. That pattern is useful, but its meaning depends on the entire path.

Who selected the destination? Was the destination already under suspicious control? Did the code travel through the service being transferred? Was the submitted value bound to the same session, number, request and time window? Could a third-party component assert success without completing the expected challenge? Did the gaining provider receive cryptographic or otherwise tamper-resistant evidence, or only a status label?

The public report does not reveal which of these questions explains the vulnerability, and this article does not speculate. They illustrate why the output “verified” cannot be separated from the mechanism that produced it. A reliable control proves a defined proposition. For a mobile port, that proposition includes the requester's right to use the number and access to the associated device. A code-sent event proves only that a system attempted to send something to a destination.

This distinction is similar to a network health check. A monitoring platform can record that it issued a probe. That does not prove the service answered correctly. A change ticket can record that an engineer selected a validation step. That does not prove the validation observed the production path. In every case, the record should capture the result, the entity tested and the evidence binding them together.

An identity workflow therefore needs more than an activity log. It needs a verifiable state transition. The request begins unverified. A permitted method is selected. Evidence is collected and checked. Success is bound to the particular requester, number and port transaction. Only then can the transaction move to an authorised state. If any link is absent, the correct result is not “probably verified”; it is “do not port”.

Why the registry record is necessary but not sovereign

Porting systems need authoritative records. Without a shared ledger, providers could disagree about which network should receive traffic for a number. Calls might loop, messages might disappear or two providers might each think the other is responsible. Accurate, unique and timely records are part of service continuity.

But the ledger records a transfer; it does not create the requester's legitimacy from nothing. If an unauthorised instruction passes the identity gate, the porting system may accurately record and distribute that instruction. The resulting network state can be internally consistent and still be wrong for the rights-of-use holder.

This is the difference between recordkeeping and sovereignty. A registry has authority over the consistency of its records within a defined process. It should not be treated as an independent source of truth about human authority when the evidence feeding the process failed. The running network may deliver every call and message exactly according to the new record, while the person entitled to use the number has lost control.

The reality layer is therefore the combined state of the user, device, identity evidence, port transaction and live routing. A single database field cannot represent that reality on its own. Operators need reconciliation across the layers: who requested the change, which device challenge succeeded, which provider initiated it, what shared transaction was created, when routing changed, and whether the previous customer suddenly lost service.

This does not weaken registries. It makes their proper role clearer. The ledger should make unique allocation and transfer auditable. It should preserve who changed what and when. It should support rollback and dispute handling. Its value rises when its entries are bound to evidence from the controls that authorised the change.

Outsourcing a component does not outsource the obligation

Modern telecommunications services depend on vendors. A provider may use outside services for identity checks, fraud signals, document analysis, messaging, customer support or workflow orchestration. Outsourcing can improve capability and scale. It also creates a boundary at which a compact vendor response may stand in for a complex process.

The dangerous version of that boundary is a binary response with no enforceable meaning. The provider sends a request to a verification service and receives “success”. The porting workflow accepts that value. If the integration can be bypassed, replayed, detached from the number or issued without the required checks, the provider's system may proceed while every dashboard says the vendor step passed.

Accountability requires the provider to define the evidence contract. What exact proposition does the vendor attest? Which input fields are bound to the result? How long is it valid? Can it be used only once? What happens when the vendor is unavailable? Does any fallback path reduce the verification standard? Which logs allow an incident reviewer to reconstruct the decision without exposing sensitive personal data?

The provider also needs release controls. A third-party update that changes verification behaviour should not flow into a critical porting path without testing against abuse cases. Configuration changes should be versioned. Failures and unexpected success rates should generate alarms. An emergency kill switch should be able to suspend the affected channel without disabling legitimate porting across every channel.

None of this means a carrier must build every identity technology itself. It means the carrier remains responsible for the decision to initiate a regulated transfer. A vendor can supply evidence or computation. It cannot absorb the carrier's legal and operational duty simply because its software produced the status consumed by the carrier's workflow.

How control of a number can reach a bank account

A mobile number often sits inside a wider identity system. Banks, email providers, social networks and government services may send alerts or recovery codes by SMS. Some use the continuity of a known number as one input when deciding whether an activity is suspicious.

If a scammer gains control of the service associated with the number, incoming calls and messages may reach the scammer's device. The legitimate user may see the old service stop working. This creates a race. The user is trying to understand a sudden loss of signal while the attacker may be attempting password resets or account recovery elsewhere.

The phone number alone should not be sufficient to take over a bank account. The ACMA announcement nevertheless records that the vulnerability enabled access to bank accounts in at least some of the affected cases. That outcome shows how a telecom handoff can become a dependency for other institutions' controls.

The correct lesson is not that SMS must never be used. It is that service providers should understand the risk attached to number-control changes. A bank can treat a recent port as a risk signal rather than ordinary continuity. A carrier can make port notifications and rapid reversal channels clear. Both can avoid relying on one possession factor for high-impact recovery.

For the carrier, the immediate obligation remains narrower and concrete: do not transfer the service until the permitted additional identity verification has succeeded. Wider ecosystem controls reduce harm, but they do not excuse a weak porting gate.

The incident is about a control plane, not a retail form

An online form is the visible entry point. Behind it is a control plane: software and records that instruct the network how to change state. In networking, a control plane decides where traffic should go, while the data plane carries the traffic. Mobile-number porting is not identical to router configuration, but the analogy is useful.

The customer's request becomes a series of instructions. Verify authority. Create the transaction. Coordinate with the losing provider and shared porting systems. Activate the service. Update routing and customer records. Notify the parties. Each instruction changes what the live system will do.

A weak web-form integration can therefore reach deep into infrastructure. If it falsely authorises a port, later network components do not need to be hacked. They may execute validly formatted instructions through ordinary interfaces. The result is an operational transfer accomplished by legitimate machinery on an illegitimate basis.

This is why security cannot end at the public form. The porting transaction should carry evidence of the gate that authorised it. Systems downstream should reject missing, expired or inconsistent evidence. High-risk patterns should pause before routing changes. Post-port observations should detect when the old service goes dark in circumstances inconsistent with the verified request.

The objective is not to put sensitive identity data into every network system. It is to carry a minimal, auditable proof that the required control succeeded for this number and this transaction. Detailed personal data can remain within the protected verification domain, while downstream systems receive a bound decision token, method identifier, time, version and trace reference.

Twelve controls that make a port defensible

First, model the number as a unique operational resource. The service record should identify the number, current provider context, rights-of-use holder relationship and active port state without confusing those concepts.

Second, keep the transaction fail-closed. No timeout, vendor error, missing callback or ambiguous response should be converted into permission to proceed.

Third, bind verification to the exact number, requester, transaction and session. A successful check from another request must not be reusable.

Fourth, make the permitted method explicit. The audit record should show which standard-compliant path was used, not merely a generic “identity passed” flag.

Fifth, distinguish delivery from verification. Sending an SMS code, presenting a challenge or opening a document check is not the same as receiving and validating the required evidence.

Sixth, use single-use, short-lived evidence. Replay resistance is essential when a successful result can authorise a transfer of communications control.

Seventh, monitor rates and shapes, not only individual failures. An unusual cluster of online ports, repeated retries, rapid changes in success rates or a channel that suddenly stops producing verification failures can reveal a bypass.

Eighth, test third-party integrations as part of the production control. Contract tests should verify required fields, binding, expiry, error handling and fail-closed behaviour whenever either side changes.

Ninth, maintain an immediate suspension path. Operators should be able to stop one affected method, vendor route or retail channel while preserving safer alternatives.

Tenth, notify through an independent path where possible. A warning sent only to the newly controlled service may reach the wrong person. Existing account channels and the prior device context can provide additional signals, subject to privacy and security design.

Eleventh, make reversal a controlled process rather than an improvised exception. The organisation needs documented authority, evidence preservation and cross-provider contacts for suspected unauthorised ports.

Twelfth, review the entire evidence chain after an incident. Counting the ports and fixing one software defect is not enough. Reviewers should determine why the control status was trusted, why monitoring did or did not detect the pattern, what downstream systems accepted and whether the same assumption exists in other channels.

These controls are understandable without specialist vocabulary. Their common purpose is simple: a network should change control of a number only when the evidence and the instruction belong to the same legitimate request.

What the penalty says—and what it cannot repair

Optus paid AUD 826,320. ACMA described that amount as the maximum financial penalty available to it in the matter and said the figure reflected the seriousness of the breaches.

The amount is part of the accountability record, but it is not a measure of total harm. Reported consumer loss was AUD 39,000, yet financial loss is only one category. Losing control of a phone service can require recovery work across accounts, identity documents, banks and communications. The public release also refers to identity theft and distress, without quantifying every effect.

Nor does the penalty tell operators the complete cost of weak verification. There are incident-response costs, customer support, remediation, regulatory investigation, vendor review and loss of trust. Some costs fall on people and institutions outside the carrier.

At the same time, this article should not invent remedies beyond the public record. ACMA's announcement says the issue was remediated quickly, but the detailed technical changes are not published in the final findings. A defensible assessment can say what the regulator found and what strong controls generally require. It cannot certify unseen remediation.

The lasting value of the enforcement action is the boundary it makes visible. A provider cannot proceed merely because a workflow has reached the port stage. Verification is not optional metadata attached to the transaction. It is the condition that permits the transaction to exist.

What the public record does not establish

The report does not identify the third-party verification supplier. It does not publish the exploit path. It does not say that 44 separate people each suffered a financial loss. It does not assign the AUD 39,000 equally among four people or prove that only four services were affected by criminal activity; the phrase is “at least four”.

The report also does not support a claim that Optus intended to authorise fraudulent ports. The finding is about systems and compliance: the required processes were not completed, and the ports proceeded.

The word “unauthorised” in the findings describes the port outcome under the evidence considered by ACMA. It should not be expanded into an unverified story about the identity, coordination or methods of every actor. Security-sensitive redactions are a reason for restraint, not an invitation to fill gaps.

Finally, the number itself should not be described as a consumer-owned entity. The rights-of-use-holder concept is more accurate. It protects the customer's legitimate authority while preserving the reality that numbers are administered within a public numbering framework and must remain unique and portable.

What an accountable port record should preserve

An incident reviewer should not have to rebuild the decision from screenshots and personal recollection. The transaction record needs enough structure to answer the core questions while avoiding unnecessary retention of identity documents.

Start with the resource and the request. Record the mobile service number in the protected system, the gaining and losing provider context, the retail channel, the transaction identifier and the time the request began. The public number should not be copied into loosely controlled analytics merely because it is essential to the protected operational record.

Next, record the authority claim. Was the requester acting as the rights-of-use holder or an authorised representative? Which permitted verification method was selected? Which policy and integration version governed the decision? The record should identify the proposition checked without turning a generic account login into port authority.

Then preserve the outcome as evidence, not just colour. A successful decision needs a unique reference, issue time, expiry time, single-use state and binding to the number and transaction. A failure needs a reason class that allows monitoring without disclosing sensitive details. A timeout or unavailable vendor needs its own state; it must not be stored as success merely to keep the workflow moving.

The port initiation should point back to that evidence. The shared transfer record, network activation and customer notification should carry the same transaction trace. This makes it possible to reconcile the control plane after the event: the port that changed live routing can be matched to the specific verification decision that allowed it.

Access and retention also require design. Identity evidence is sensitive. Not every network operator or support worker needs to see it. A layered record can keep detailed evidence in a restricted system while exposing only the minimum proof, status and trace reference to porting and network components. Retention periods should satisfy legal, dispute and investigation needs without creating an indefinite identity-data archive.

Finally, the record must survive vendor boundaries. If a third party performs a check, the provider should retain enough signed or otherwise integrity-protected evidence to show what the vendor asserted under which version. A vendor dashboard that can change or disappear is not a durable audit trail.

This record is not bureaucracy added after the control. It is part of the control. It makes false success harder to hide, lets monitoring compare authorised decisions with actual ports and gives responders a reliable basis for suspension or reversal. Most importantly, it prevents the final registry state from becoming the only surviving story about how operational authority changed.

Why this case matters beyond one brand

Every provider that ports numbers operates the same kind of boundary. A human request crosses into a technical control system. Identity evidence becomes an authorisation decision. The decision becomes a shared transfer record. The record changes live routing and service control.

The boundary is attractive to attackers because the downstream systems are designed to cooperate. Once a request is accepted, automation can complete the transfer quickly. Speed is beneficial for legitimate customers and dangerous when the gate is wrong.

The case also matters to enterprises that outsource identity decisions. A vendor integration is not just a procurement item. When its result authorises a high-impact change, it becomes part of the operator's control plane. Its semantics, failure modes and monitoring deserve the same discipline as network change interfaces.

For regulators and industry bodies, the incident reinforces the importance of evidence-rich records. A port ledger should help reconstruct the authorised chain without exposing more personal information than necessary. Standardised reason codes, verification-method identifiers and trace references can support oversight while keeping sensitive data in protected systems.

For non-specialist readers, the central point is straightforward. The number printed in a contact list may look like ordinary data. In the network, it is a unique route to a person's communications. Changing who controls that route is a consequential infrastructure action. It deserves proof before execution, observation during the change and a clear recovery path afterward.

Sources