Summary

  • Mobile-number porting lets a customer keep the same number while changing provider. Because the provider serving the number changes, a fraudulent port can redirect calls, texts and security codes without changing the familiar number seen by other people and services.
  • The Australian Communications and Media Authority, or ACMA, found that Lycamobile breached anti-scam requirements on 131 occasions between September and December 2024 after scammers exploited weaknesses in its systems. The 131 figure counts regulatory occasions or instances, not victims, unique numbers or proven loss events.
  • ACMA reported consumer losses of at least A$175,000. It did not publish the number of consumers behind that loss floor or say that every one of the 131 instances caused financial loss.
  • Lycamobile paid two infringement notices totalling A$376,200. The notices selected 18 and one alleged contraventions respectively. Those 19 notice items are not the full 131-instance investigation set, and payment was not a court merits judgment or criminal conviction.
  • The 18-month court-enforceable undertaking creates a forward-looking assurance programme. It requires recurring independent testing, audits, implementation responses, reporting, training and records, but it does not by itself prove that remediation is complete.
  • The lasting accountability question is simple: can the provider show that the required check executed for this exact transfer, or can it show only that a protocol was configured somewhere in the system?

Analysis

What happened

Mobile-number portability is the process that allows a person to change mobile provider without losing the number through which family, colleagues, banks and other services already reach them. The provider receiving the number is called the gaining provider. The provider that previously served it is the losing provider. A successful port changes which carrier network delivers service for that number while the digits remain the same.

That continuity is valuable. It reduces the disruption of changing provider and helps customers leave a service without rebuilding their contact identity. It also creates a high-consequence transfer point. If the requester is an attacker rather than the legitimate rights-of-use holder, the transfer can make calls and messages for the familiar number arrive on a service controlled by someone else.

ACMA's public enforcement package says scammers exploited weaknesses in Lycamobile's systems during mobile-number port requests. The regulator found that the prescribed additional verification steps did not occur on 131 occasions between September and December 2024. ACMA reported consumer losses of at least A$175,000 and said the gaps were exploited for more than three months without detection.

The phrase “rights-of-use holder” needs a short explanation. A customer does not own a phone number in the same way that a person owns a house. The number belongs to an administered numbering system, while the customer has the recognised right to use it through a service. Porting is meant to preserve that legitimate use while moving the service relationship. The verification step tests whether the requester is that person, or someone authorised to act for them, and whether the requester has the required access associated with the mobile service.

The public documents do not reveal the detailed path used to bypass the checks. They do not name an endpoint, software component, credential, supplier, employee or precise attacker technique. The defensible account is narrower: Lycamobile described unidentified system flaws that allowed prescribed protocols to be circumvented; ACMA found that the required verification process did not occur in the 131 instances.

That boundary matters for two reasons. First, unsupported technical detail can mislead readers about what was proved. Second, publishing a guessed exploit description can distract from the control failure that the record does establish. The central question is not which fashionable attack label applies. It is how a gaining provider allowed a port to proceed without reliable evidence that the required verification step had actually run.

Why this is network infrastructure, not generic cybercrime

The harm pathway depends on the mobile network's transfer machinery. The current Australian Mobile Number Portability Code describes automated interfaces between industry participants and the distribution of routing information when the carrier network serving a number changes. In ordinary language, different systems have to agree that the number now belongs on a different service path and then direct communications accordingly.

The number itself remains recognisable. That is what makes portability convenient, and it is what makes an unauthorised port deceptive. A friend may still call the same digits. A bank may still send a code to the same digits. The visible identifier does not announce that the service behind it has moved.

An unauthorised port therefore differs from the theft of a password in a stand-alone online account. It changes an operator-controlled network relationship. The gaining provider initiates a transfer that affects reachability, message delivery and the continuity of an administered numbering resource. The resulting exposure may extend into banking or account recovery, but the incident-specific control surface begins with the mobile service handoff.

This direct connection is important for accountability. A generic statement that “companies must take cyber security seriously” would add little. The useful questions are concrete. Which provider owned the pre-port decision? Which approved verification process was used? What evidence was bound to the request? What prevented a different system path from skipping that evidence? What monitoring would detect a successful port without a matching verification record?

Remove mobile-number porting from this case and the regulatory duty, transfer mechanism and reported harm path no longer make sense. That is why the event belongs in a discussion of network-infrastructure control rather than a broad catalogue of online fraud.

What the pre-porting rule required

The Telecommunications (Mobile Number Pre-Porting Additional Identity Verification) Industry Standard 2020 remains in force. Its section 8 places a clear obligation on the gaining carriage service provider before it initiates a port. The provider must use one of the approved additional identity-verification processes to confirm the requester is the rights-of-use holder, or an authorised representative, and has the required access to a mobile device associated with the number. It must not proceed unless the prescribed process has been used.

The word “additional” is significant. A person seeking a port may know account details, names, addresses or other information obtained elsewhere. The standard does not treat ordinary account data as sufficient by itself. It requires a further process tied to entitlement and device access.

The rule also identifies the decision owner. Porting involves more than one organisation, but the gaining provider controls the gate before it asks the industry process to move the service. That assignment avoids an easy accountability gap in which every participant points to another part of the chain.

Compliance cannot be shown merely by producing a policy that says the check is mandatory. It also cannot be shown merely by demonstrating that a verification screen exists. The operational evidence has to connect the required process to the exact request that was allowed to proceed.

Imagine two records created a few seconds apart: one says a person completed a verification step; the other says a particular number was ported. If the system cannot prove those records belong to the same person, number, request, channel and valid time window, it has activity data but not reliable authorisation evidence. A strong control makes that binding unavoidable.

Reading 131, A$175,000 and A$376,200 correctly

Regulatory cases often contain several numbers drawn from different legal instruments. Combining them carelessly can create claims that none of the documents makes.

The broadest event count here is 131. ACMA described 131 breach occasions or instances between September and December 2024. The figure does not establish 131 victims. It does not establish 131 unique mobile numbers, 131 completed fraudulent ports, 131 bank-account compromises or 131 separately successful scams. A single person or number could in principle appear more than once, but the public record does not give enough detail to calculate a unique denominator.

The harm figure is also bounded. ACMA reported consumer losses of at least A$175,000. “Reported” identifies the origin and scope of the information. “At least” makes the amount a floor, not a complete valuation. The release does not state how many consumers reported those losses, how the losses were distributed, how much was recovered or reimbursed, or whether every relevant effect was financial.

The paid-notice total comes from a narrower legal selection. One infringement notice dated 20 October 2025 specified A$356,400 and listed 18 selected alleged contraventions between 13 November and 6 December 2024. A second notice dated 13 November 2025 specified A$19,800 and listed one selected alleged contravention on 13 November 2024. Together the two amounts equal A$376,200, and together the notices contain 19 selected items.

Those 19 notice items must not be presented as all 131 investigation instances. An infringement notice is an administrative enforcement instrument based on an authorised officer's reasonable-grounds belief about alleged contraventions. ACMA's investigation report and current register separately record the regulator's findings. The documents perform different functions and use different populations.

Payment also needs precise language. ACMA's enforcement policy explains that paying an infringement notice discharges liability for the alleged contravention without litigation. It is not a court merits judgment, a criminal conviction or proof that a court tested every factual proposition. The separate undertaking is described as court-enforceable because the statutory promise can be enforced through a court mechanism. That label does not mean a court adjudicated the underlying 2024 conduct.

Precision is not a favour to the company. It is part of credible accountability. Inflating a denominator or changing an administrative notice into a court verdict makes the article easier to challenge and harder for readers to trust. The documented facts are serious without embellishment.

Lycamobile's position and ACMA's answer

The investigation report records Lycamobile's response to ACMA's preliminary findings. The company submitted, in substance, that unidentified system flaws allowed prescribed protocols to be circumvented even though it had systems and protocols intended to comply, and that an external third party exploited those flaws. It argued that these circumstances should affect the regulator's conclusion about compliance.

ACMA rejected that position. The regulator's reasoning focused on what the systems actually allowed to happen. Robust systems were required to ensure the prescribed process functioned, and the prescribed verification steps did not occur in the 131 instances.

Both parts should be presented together. Omitting Lycamobile's submission would remove an important account of how the company described the incident. Repeating the submission without ACMA's response would obscure the regulator's central finding.

The exchange reveals a recurring problem in technology assurance. An organisation may be able to point to policies, protocols, screens, vendors and design documents that look compliant. Yet the live service may contain a sequence, interface or exception that allows the protected action to occur without the required state. If that happens, the existence of the intended control does not establish the effectiveness of the operating control.

This does not mean every defect creates legal liability in the same way. It means the evidence needed for a high-consequence transfer must come from the execution path, not only from the design intention. A system is accountable for the state change it permits.

The difference between a configured check and an executed check

Consider a simplified porting service. A customer starts a request. The provider asks for additional verification. A separate service records a successful result. The porting function then sends the transfer through industry interfaces. On a process diagram, the steps form a neat line.

The real system may be more complicated. A request can begin through a website, an app, an assisted-support channel or an internal service. It can pause and resume. Staff may handle exceptions. Components may retry after an error. Older interfaces may coexist with newer ones. Data may be copied between systems that use different identifiers.

Every additional path creates a question: does the porting function require the same trustworthy verification state, or does it merely assume that another component performed the check? If the assumption can be broken, the control may exist in one path while another path reaches the final action without it.

The safest design binds evidence to the transaction. A verification result should identify the number, requester, approved method, relevant device or channel, time, request identifier and permitted next action. It should expire. It should not be reusable for another number or request. The service that initiates the port should validate that exact result before it can move state from pending to authorised.

The system should also record negative results and blocked attempts. A list of successful checks tells only part of the story. Repeated failures, reordered steps, unusual retries and attempts to reuse proof can reveal an attacker testing the boundary.

This model creates an auditable chain:

  1. A unique request begins before verification.
  2. The number, requester, channel and receiving provider are bound to that request.
  3. An approved additional-verification method records a result on the server side.
  4. The result is short-lived and valid only for that request.
  5. The porting service refuses to proceed if the result is missing, expired, mismatched or previously used.
  6. The carrier-interface handoff carries a traceable reference back to the authorised request.
  7. Completion, failure, cancellation and reversal remain connected to the same evidence chain.

The public Lycamobile documents do not say whether this exact model existed or which technical step failed. It is a control model derived from the regulatory requirement and the kind of evidence needed to prove execution. It should not be mistaken for a description of the undisclosed exploit.

Why more than three months without detection matters

ACMA's chair said criminals exploited gaps for more than three months without detection. That statement does not reveal when the flaw was introduced or which event finally exposed it. It does show why prevention alone is insufficient.

High-consequence controls need two independent lines of evidence. The first line stops an invalid request. The second line looks for signs that the first line did not work. If both depend on the same assumption, one bypass can defeat prevention and remain invisible to monitoring.

A useful reconciliation starts from the outcome rather than the intended process. For every successful port, can the provider find one valid additional-verification result bound to that exact request? If a port has no matching evidence, the exception should trigger investigation even when no customer has complained.

Other signals can help. A sudden loss of service, a reversal request, repeated failed verification, a cluster of requests from an unusual channel, or a port completed after an abnormal sequence may deserve attention. None proves fraud alone. Together they can shorten the time between a control gap and a response.

Customer complaints remain important, but they are a late signal. By the time the legitimate user realises calls or texts have stopped arriving, downstream harm may already be possible. The operator should aim to discover evidence breaks before the customer has to explain them.

Detection quality also depends on ownership. Fraud staff may see complaints. Engineers may see unusual service calls. Porting operations may see reversals. Customer support may see sudden loss-of-service reports. If those signals remain in separate queues, each can appear too small to justify escalation. A single investigation view can expose their common link.

Who may be affected, and what remains unknown

The immediate risk falls on the legitimate person whose mobile service is transferred without authority. They may lose the ability to receive calls and messages while still appearing reachable to everyone using the familiar number. They may have to persuade multiple providers to identify, stop and reverse the transfer.

Other services may also rely on possession of the number. IDCARE explains generally that unauthorised porting or SIM swapping can redirect password-reset messages and authentication codes. The ACCC similarly warns that criminals can use unauthorised transfers to steal identity or money. These sources explain the mechanism; they do not prove the exact chain for any named Lycamobile customer.

The public record leaves substantial unknowns. It does not state the number of consumers represented by the A$175,000-or-more loss floor. It does not divide the 131 occasions into attempts, completions, blocks or reversals. It does not publish the relationship between each occasion and each reported loss. Recovery, reimbursement and compensation outcomes are not set out.

Nor does the record identify the technical root cause in full. It does not disclose the code, endpoint, authentication flow, deployment history, vendor role, internal owner or attack method. “Unidentified system flaws” is an attributed description from the company's regulatory response, not a public forensic explanation.

An honest article keeps those unknowns visible. It can explain what a strong control would require without pretending that the public documents reveal exactly which component failed.

The 18-month undertaking is an assurance programme, not a finish line

Lycamobile and ACMA executed a court-enforceable undertaking on 23 December 2025. ACMA's February 2026 release described its term as 18 months. The undertaking does more than ask for a one-off fix. It creates a recurring programme intended to test systems, turn findings into implementation work and report progress.

An independent consultant must perform security and penetration testing at months 3, 9 and 15. Penetration testing is a controlled attempt to find ways through a system's defences. The reports are to cover findings, root causes of detected issues, the effectiveness of policies and controls, the scope and limitations of the work, and the effectiveness of Lycamobile's responses.

Lycamobile must prepare a Board-approved implementation response within two months of a consultant report. That matters because a technical finding without an owned response can remain open indefinitely. A useful implementation response identifies what will change, who owns it, the deadline, the acceptance test and the evidence that will show the unsafe state is no longer reachable.

The undertaking also requires quality-assurance audits every three months and reports to ACMA at months 7, 13 and 18. Training and record-keeping obligations support the programme. The combination creates several chances to challenge the original assumptions rather than relying on a single snapshot.

These obligations should not be reported as completed results. As of the article date, the frozen public source set does not include the consultant reports, detailed audit findings or a public account of every implementation response. A required test is not the same thing as a passed test. A scheduled report is not evidence that every recommendation has been closed.

The undertaking also does not reveal the original root cause merely because it requires future reports to address root causes of issues those tests detect. The programme can improve assurance while public technical detail remains limited.

The correct forward-looking question is therefore not “Has the existence of an undertaking solved the problem?” It is “What evidence will the testing, audits and Board responses produce, and will that evidence show that every live port path enforces the same requirement?”

A practical evidence model for every port

For a non-specialist, the key distinction can be put in one sentence: a provider should be able to show not only that it asked for identity verification, but that a valid result for this person and this number was the reason this transfer was allowed.

That proof can be organised around several fields. The request needs a unique identifier. The number and gaining provider need to be fixed. The approved verification method and result need timestamps. The evidence must identify the relevant device or channel in the way the standard requires. The final authorisation should reference the same request. Any manual exception should record who approved it, why, for how long and under which secondary safeguard.

The evidence should survive the handoff between business systems. A customer-facing page may collect data, a verification service may make a decision, and a porting component may communicate with industry interfaces. Each component can use a different internal identifier. If the identifiers cannot be reconciled reliably, an auditor may be unable to tell whether a successful check authorised the same transfer that later completed.

Logs alone are not enough if they record only activity. “Verification service called” does not mean “approved method completed successfully.” “Port request created” does not mean “request tied to the verified rights-of-use holder.” Evidence needs meaning, integrity and a traceable relationship to the outcome.

The provider also needs to protect the evidence itself. A record that can be altered without trace, overwritten during a retry or disconnected from a cancelled request can create false confidence. Access controls, retention, tamper-evident history and accurate clocks support the business control.

Reversals deserve the same attention as initial ports. When a legitimate customer reports an unauthorised transfer, the provider should be able to reconstruct the request quickly, preserve relevant records, coordinate restoration and connect the incident to similar signals. A reversal that closes a customer-service ticket without feeding back into control testing wastes an important warning.

The goal is not to collect every possible data point forever. It is to maintain the minimum evidence that proves entitlement, execution and outcome, with enough security metadata and continuity to support investigation. Excess data can create privacy risk without improving the decision. Evidence design should start from the question the provider must answer.

Tests that challenge the real path

Happy-path testing asks whether a legitimate customer can complete a port. That is necessary for usability, but it does not show how the system behaves when someone tries to skip, alter or reuse evidence.

Negative tests deliberately present unsafe states. What happens if the verification result is missing? What if it belongs to another number? What if it has expired? What if the same result is replayed? What if the steps arrive out of order? What if a retry changes one identifier? What if an assisted channel takes a different route to the same porting function?

The expected answer should be consistent: the port stops safely and creates an alert or reviewable record. “Fail closed” is the common technical phrase. It means that when the required proof is absent or uncertain, the system does not continue with the high-consequence action.

Testing should cover every live channel that can reach the transfer action, not only the most visible website. It should be repeated after material changes to interfaces, identity services, workflow engines, vendor integrations and exception procedures. A test that passed before a release may no longer describe the running system after it.

Independent testing adds a different perspective, but independence is not a substitute for scope. A consultant can test only what is included and accessible. Reports should make limitations visible: which environments, channels, roles and sequences were tested; which were excluded; and whether the work validated transaction evidence as well as perimeter security.

Regression tests should preserve every confirmed weakness as a permanent challenge. Once a bypass class is understood, the provider should be able to demonstrate after each relevant change that the unsafe sequence still fails. Closure is not “patch deployed.” Closure is “unsafe state blocked, evidence retained and independent retest passed.”

Measures that reveal the real condition

Management dashboards often count activities because activities are easy to count: training sessions held, tests completed, policies reviewed and alerts generated. Those measures can show effort, but they do not directly show whether a porting control works.

Outcome-oriented measures ask different questions. What share of successful ports has a complete, valid and transaction-bound verification chain? How many ports lack a matching result? How old is the oldest unexplained exception? How long passes between an alert and containment? How many corrective actions have passed independent retest? Which channels are included in the denominator?

The denominator is crucial. A statement that 100 per cent of reviewed ports passed can mislead if only one channel or a small sample was reviewed. Reports should show the total population, excluded records, reasons for exclusion and whether the result can be reproduced from source evidence.

Trend information is useful when it preserves context. A rise in reversals may indicate better detection, greater attack volume, a new control weakness or a change in reporting. The number alone cannot decide. Analysts need to connect it to verification failures, channel changes, complaints and known remediation work.

Board reporting should separate open risk from completed activity. A recommendation can be accepted yet overdue. A control can be deployed yet untested. A test can be completed yet limited in scope. Clear status categories prevent those stages from collapsing into a reassuring but inaccurate “done.”

Legitimate portability should remain easy for the rightful user

The lesson is not that changing provider should become difficult or subject to arbitrary permission. Portability protects competition, continuity and customer choice. A person should not lose a familiar number merely because they seek better price or service.

Strong verification supports that objective when it focuses on reliable evidence and predictable exceptions. A customer with a damaged device, an accessibility need or an unusual account circumstance may require assistance. The answer is not an undocumented override. It is a controlled exception with explicit authority, a recorded reason, a limited lifetime, secondary evidence and later review.

Adding forms that do not bind the final action would create permission theatre: more visible friction without stronger protection. The useful control is the one that changes what the running system can do. It blocks an unauthorised state while allowing a well-evidenced legitimate transfer to continue.

This balance also helps operations. When evidence is clear and transaction-bound, staff can resolve disputes and reversals faster. The customer does not have to navigate an argument between organisations about which step was supposed to happen.

Governance across technology, fraud and customer operations

Porting accountability does not fit neatly inside one department. Engineering owns service behaviour. Fraud teams interpret suspicious patterns. Compliance interprets the standard and enforcement obligations. Customer operations hear early reports of lost service. Executives allocate resources and accept residual risk.

Fragmented ownership creates a familiar failure. Each team can complete its assigned activity while nobody owns the end-to-end outcome. Engineering may show that a verification service is available. Compliance may show that a procedure exists. Operations may close individual complaints. The unanswered question is whether every successful port can be traced to valid evidence.

One named senior owner should hold that outcome across channels. The owner needs a view of successful ports without complete evidence, unresolved control defects, aged audit findings, reversals, suspicious requests, customer harm and retest status. Training completion belongs in that view, but it cannot substitute for it.

The Board-approved response required by the undertaking is an opportunity to make ownership concrete. Each recommendation should identify the unsafe state, the planned barrier, the accountable person, the deadline, the test and the proof of closure. If management rejects or narrows a recommendation, the reason and residual risk should be visible.

Supplier involvement does not move accountability away from the provider controlling the port. A third-party service may perform part of verification or testing, but the gaining provider still needs evidence that the whole path works. Contracts can allocate tasks; they cannot turn an unverified transfer into a verified one.

What the public record proves, and what it does not

The public sources support a firm but limited account. ACMA found breaches on 131 occasions between September and December 2024. It reported that scammers exploited system weaknesses and that consumer losses were at least A$175,000. It recorded two paid infringement notices totalling A$376,200 and accepted an 18-month undertaking.

The investigation report supports the finding that the prescribed verification steps did not occur in those instances. It also records Lycamobile's explanation about unidentified flaws and circumvention, and ACMA's rejection of the company's compliance argument.

The Federal Register supplies the operative verification rule. The Mobile Number Portability Code explains the carrier and routing mechanism. ACCC and IDCARE guidance independently explain the general harm path from an unauthorised transfer. Those supporting sources do not independently verify the Lycamobile-specific counts or losses.

The public record does not provide victim-level files or an independent forensic report. It does not show the precise exploit, complete root cause, introduction date, affected code, internal owner or supplier role. It does not reveal all attempts, completed transfers, reversals, losses, recoveries or compensation.

The enforcement package also does not prove that all present-day risk has ended. The undertaking defines future assurance work; it is not a certificate of completion. Any later public assessment should distinguish between obligations scheduled, work performed, recommendations accepted, changes implemented and results independently retested.

What to watch next

The first test is evidence coverage. Can Lycamobile reconcile every successful port to one valid additional-verification result bound to the same request? The useful figure includes all channels and reports exclusions. An unexplained gap should be investigated even when no loss complaint exists.

The second test is the scope and result of independent security and penetration work. The undertaking schedules work at months 3, 9 and 15. Public reporting may remain limited, but governance bodies and ACMA should be able to see whether testing covered every route to the porting function, included negative sequences and retested corrective work.

The third test is implementation discipline. Board-approved responses should turn findings into dated actions with acceptance criteria. A recommendation should not disappear into a general technology programme without an owner and an evidence-based closure test.

The fourth test is detection speed. The case involved gaps exploited for more than three months without detection. Monitoring should be judged by how quickly it surfaces a successful port with missing or inconsistent verification evidence, not only by how many alerts it generates.

The fifth test is the handling of exceptions and reversals. A manual pathway created to help legitimate customers must enforce equivalent evidence, record authority and expire safely. Reversal requests should feed control testing and pattern analysis rather than remain isolated service tickets.

The sixth test is public precision. Later statements should keep the 131 investigation instances, 19 selected notice items, A$175,000-or-more reported loss floor and A$376,200 paid-notice total separate. Clear numbers make progress measurable and prevent a future report from appearing stronger than its evidence.

The durable lesson

A mobile number is a continuity resource. Its digits can stay constant while the carrier network and person receiving communications change. That makes the transfer process both useful and sensitive.

Lycamobile's case shows why a protocol cannot be assessed only by its presence in policy or configuration. The question is whether the running system required a valid result for the exact transaction, refused every unsafe path and left evidence that monitoring and auditors could inspect.

The answer is not to weaken portability. It is to make the legitimate transfer real in both operation and record: verify the rights-of-use holder, bind the result to the port, preserve the evidence, test bypasses, reconcile outcomes, detect gaps quickly and give leaders an honest account of what remains open.

A porting ledger records a change; it does not make the change legitimate merely by accepting it. Legitimacy comes from the verified right to use the number and the functioning control that protects that right. The record should follow reality, and the running system must prove it.

Sources