Vodafone Portugal's 2022 Core-Network Recovery Made Telecom

Summary

Vodafone Portugal said a network outage began on the night of 7 February 2022 because of a deliberate and malicious cyberattack intended to cause disruption. Its first statement identified effects on 4G/5G, fixed voice, television, SMS and voice or digital customer-care services. [1]
The initial recovery did not restore every service at once. Mobile voice returned across almost all of Portugal, while mobile data was initially available only over 3G. Contemporary reporting attributed restoration of 2G voice to about 22:30 on 7 February. [1][17]
Vodafone later said its teams moved from a 2G/3G fallback state to 4G/5G in less than 24 hours. At the end of the week, it described the network as stabilised but still allowed for isolated instability. [3]
Vodafone Group's annual report said 4.7 million mobile customers and one million fixed-line customers were affected. Those are subscription and line counts from the operator, not a single count of distinct people or identical service failures. [6]
ANACOM later described a 2022 incident of enormous impact involving a cyberattack on a major operator's core network, with nationwide effects on fixed and mobile communications. ANACOM's broader annual totals cover all notified incidents and must not be assigned wholly to Vodafone. [8]
Vodafone said at the time that it had no indication customer data had been accessed or compromised. That is an attributed, time-bounded statement. The available public record does not prove the attacker, vector, exploited system, malware or exact destructive action. [1][15]
Accountability is not the same as blaming the victim of a malicious act. It asks whether authority over shared core, identity, policy and management systems was matched by segmentation, recoverable state, fallback capacity, service-priority rules and independent evidence of repair.
The 2G and 3G fallback shows that legacy layers can preserve critical communications. It also raises measurable questions about capacity, coverage, device support, emergency calling, roaming and which services remained coupled to damaged systems.
A credible restoration claim should be tied to service-specific evidence: mobile registration, call completion, data-session establishment, SMS delivery, fixed voice, television, enterprise applications, international connections and customer-care availability.
EECC security obligations and ENISA guidance provide a useful evidence framework for risk management, incident management, business continuity, monitoring, audit and testing. They do not, by themselves, establish a Vodafone legal violation or regulator finding. [18][19]

Recovery through older generations revealed the real infrastructure boundary

The most revealing fact in the Vodafone Portugal incident is not the word "cyberattack." It is the order in which communications returned.

Vodafone's first public statement said the disruption affected services based on its data network, including 4G and 5G, fixed voice, television, SMS and customer-care channels. The operator said mobile voice was available again across almost all of Portugal and mobile data was available exclusively through 3G. [1]

Contemporary Portuguese reporting added a more granular account. Vodafone Portugal chief executive Mario Vaz was reported as saying that 2G voice had been restored at about 22:30 and that 3G data was operating while teams worked toward 4G restoration. [17]

Vodafone's later stabilisation statement described an intense rebuild that moved the network from 2G and 3G to 4G and 5G in less than 24 hours. By the end of the week, mobile and fixed voice, data and television were described as stabilised, with a warning that isolated instability could still occur. [3]

That chronology turns abstract resilience into an observable architecture.

The network did not have one undifferentiated "up" state. It had layers, service dependencies and recovery priorities. Some voice service could operate on an older radio and core path before newer packet services returned. Mobile data could function on 3G while 4G and 5G remained under repair. Fixed, television, SMS, customer-service and enterprise functions had their own dependencies and restoration sequences.

This matters because a resilience claim is only as good as the failure boundary it describes. An operator might have redundant radio sites while relying on shared subscriber databases, policy systems, transport, DNS, authentication, provisioning or management credentials. It might have physically separate data centres while using one administrative plane. It might have a fallback radio generation that still depends on common identity, signalling or billing systems.

The public sequence does not disclose Vodafone's private topology. It does show that technology generations and services failed and recovered differently. Any serious accountability analysis should begin there, rather than treating the incident as one security event with one recovery time.

The test is practical: for each service, which components had to remain trustworthy and reachable before the service could return?

For 2G voice, that could include radio access, switching, subscriber identity, signalling, interconnection and operational control. For 3G data, it could include packet-core functions and transport paths distinct from the affected 4G/5G environment. For fixed voice and television, it could include access aggregation, service platforms, DNS, authentication and customer equipment. For enterprise applications and international connections, it could include private network gateways, roaming, interconnect and support systems.

The incident therefore belongs squarely in network-infrastructure accountability. The attack may have been malicious, but the public harm followed the structure of communications systems and the controls available to contain, bypass and rebuild them.

One event coupled services that customers experience as separate products

Retail communications are sold as different services. A customer can buy mobile voice, mobile data, fixed broadband, television, enterprise connectivity and support. Operationally, those services can converge on shared systems.

A mobile network needs more than antennas. Devices must register. Subscribers must be authenticated. Sessions must be created and governed by policy. Voice calls need switching or packet voice functions. SMS uses specialised messaging infrastructure. Traffic must cross transport and interconnection networks. Roaming requires trusted exchanges with other operators. Operations teams need management systems that can configure, observe and repair all of those layers.

Fixed and television services can share transport, identity, DNS, customer records, provisioning and operational tooling with mobile services. Customer-care systems depend on network reachability and back-office platforms. Enterprise products can depend on gateways, private access, managed security and international connectivity.

Vodafone Group's cybersecurity factsheet said the Portugal incident involved loss of some voice and data services, television, enterprise and business applications, and international connections. [7] The Group annual report said 4.7 million mobile customers and one million fixed-line customers were affected. [6]

Those disclosures do not prove that one physical machine failed. They show functional coupling at national scale.

Coupling is not automatically negligent. Converged infrastructure can improve efficiency, observability and service delivery. A shared platform can be engineered with fault domains, independent recovery paths and strong access controls. The accountability issue is whether convergence hides correlated risk.

A useful dependency review would ask:

Which services depend on the same subscriber or identity store?
Which depend on the same management credentials or administrative domain?
Which recovery tools are hosted inside the environment they must repair?
Which configuration and software repositories can be altered through the same privileged path?
Which network generations share signalling, transport, DNS, time, orchestration or monitoring?
Which fixed and mobile products use common customer, provisioning or policy systems?
Which international and enterprise links depend on the same control plane?
Which status and support channels fail when the production network fails?

The answer should be a current dependency graph, not only an architecture presentation.

If a shared component can interrupt millions of subscriptions, it should have an explicitly defined failure domain. If an administrative identity can change several service platforms, it should have segmented authority and independent monitoring. If a recovery tool depends on the damaged core, there should be an out-of-band path.

The 2022 incident made these questions public because the outage crossed product boundaries. The responsible conclusion is not that all convergence is unsafe. It is that common dependencies create a burden of proof proportional to the number of services and people they can affect.

Malicious intent does not cancel the operator's resilience duty

Vodafone Portugal described the event as a deliberate and malicious cyberattack intended to cause damage and disruption. [1] That attribution matters, but it can distort accountability if it becomes the end of the analysis.

An operator does not control whether a hostile actor attempts an intrusion. It does control many of the conditions that determine whether one compromise becomes a nationwide communications failure.

Those conditions can include:

the reach of privileged identities;
separation between corporate IT and network operations;
segmentation among mobile-core, fixed, television and support systems;
the ability to alter configuration and software images;
backup immutability and offline recovery;
clean administrative access;
independent monitoring;
service fallback;
incident authority;
tested restoration procedures.

Calling the operator a victim is accurate and incomplete. Calling the attacker responsible is accurate and incomplete. Infrastructure accountability asks what preventable amplification remained within the operator's practical control.

This distinction avoids two bad conclusions.

The first is victim blaming. Public sources do not establish that Vodafone ignored a known vulnerability, failed a specific legal requirement, or made an unreasonable decision. The available public record contains no authenticated technical postmortem and no enforcement decision. It would be irresponsible to infer negligence from service loss alone.

The second is fatalism. A malicious act does not make the blast radius inevitable. Telecommunications networks are designed on the assumption that equipment, software, links, sites and people can fail. Cybersecurity extends that assumption to credentials, management systems, orchestration and stored state. Resilience exists precisely because the initiating event may not be preventable.

The accountability question is therefore conditional:

Given the authority an attacker obtained, what independent controls could still limit service impact?

A compromised administrative account should not automatically control every network generation. A damaged 4G or 5G core should not necessarily eliminate all legacy voice. A corrupted orchestration layer should not be able to rewrite every clean backup. A loss of primary monitoring should not leave responders blind. A failure of customer-care systems should not eliminate public status communication.

The Vodafone recovery sequence suggests that some fallback and rebuilding controls worked. That deserves recognition. Accountability is not a hunt for failure alone. It should identify controls that reduced harm as well as gaps that require evidence.

The public record does not establish the attack vector

Major incidents create a market for confident explanations. The Vodafone Portugal outage is a case where restraint is part of technical accuracy.

The public record reviewed here does not establish:

the attacker or group;
the initial access method;
a compromised credential;
a phishing message;
a supplier breach;
malware or ransomware;
a software vulnerability;
an insider;
a nation-state;
the exact system reached;
the precise destructive action.

Vodafone said the incident was deliberate and malicious. Portuguese cybersecurity reporting later described disruptive or destructive effects. [1][10][11] These statements support an intentional disruption boundary. They do not supply a forensic chain.

The record leaves no basis for filling that gap with familiar narratives.

No public evidence reviewed here proves that ransomware encrypted network systems. No source proves that Lapsus$ or another named group was responsible. No source identifies a management vendor, virtualised network function, hypervisor, domain controller, orchestrator or subscriber database as the initial failure point. No source establishes that data destruction occurred in every affected environment.

The same restraint applies to customer data.

Vodafone's first statement said there was no indication at that time that customer data had been accessed or compromised. [1] Reuters reported the operator's assurance while noting the investigation. [15]

"No indication" is useful information. It narrows what the operator knew and communicated at that point. It is not the same as a completed independent forensic conclusion. A careful account should preserve the phrase's time and ownership.

The lack of a public technical postmortem is itself relevant to accountability, but not because the public is entitled to exploit details. Operators can protect sensitive architecture while still publishing:

the affected service boundary;
the class of control that failed;
the containment sequence;
the restoration criteria;
the scope of independent assurance;
the controls changed;
the tests used to validate repair;
remaining risk.

That level of disclosure would allow customers, regulators and peers to assess resilience without turning a postmortem into an attack guide.

Legacy networks became active resilience capacity

Telecom operators often describe 2G and 3G as legacy technologies scheduled for retirement. During this incident, they became recovery infrastructure.

Vodafone's public sequence says voice service returned broadly while mobile data was initially available only over 3G. Contemporary reporting said 2G voice was restored first, followed by 3G data, while 4G and 5G were rebuilt. [1][3][17]

That fallback demonstrates diversity across generations. It also shows why the value of legacy infrastructure cannot be measured only by ordinary traffic volume.

A fallback network may carry relatively little traffic on a normal day yet preserve essential service during a modern-core failure. Its resilience value depends on several factors:

whether devices can attach to it;
whether SIM and subscriber systems remain available;
whether voice and emergency calling work;
whether sufficient spectrum and radio capacity remain;
whether geographic coverage is adequate;
whether transport and switching are independent;
whether roaming users can connect;
whether machine-to-machine devices support the older generation;
whether operations staff can configure it safely during an incident.

Fallback also has limits.

Older networks may have less data capacity, fewer security features and shrinking device support. A customer using a 5G-only service cannot be assumed to receive an equivalent experience on 3G. A fixed, television or enterprise service may have no mobile-generation fallback at all. Congestion can appear when millions of devices attempt to attach to a layer designed for a smaller residual load.

The correct evidence is therefore not simply "3G worked."

An operator should be able to show:

attach success by region and device class;
call setup and completion;
emergency-call success;
packet-session establishment and throughput;
SMS delivery;
congestion and rejection rates;
roaming performance;
time to restore each service;
customers and services without a fallback path.

That evidence informs retirement decisions.

The broader policy lesson is that when a fallback generation is removed, its continuity function must be replaced intentionally. Modernisation should not silently convert a multi-layer failure boundary into one common core with one recovery path.

The 2022 incident does not prove that 3G should be retained indefinitely. It proves that decommissioning decisions should identify the resilience function being retired and demonstrate the tested alternative.

A less-than-24-hour restoration claim needs a service matrix

Vodafone's stabilisation statement said teams restored the equivalent of a decade of technological evolution in less than 24 hours, moving from 2G and 3G to 4G and 5G. [3]

That is a powerful recovery claim. Its accountable form is a matrix.

Which service was restored, where, for whom, and against what test?

An operator can truthfully report that 4G signalling is available while some data sessions still fail. It can restore mobile voice while SMS queues remain delayed. A television platform can load while replay functions remain unavailable. Fixed voice can work for most customers while some access regions remain unstable. An enterprise gateway can be reachable while individual applications or international routes lag.

The phrase "network restored" compresses these differences.

A service matrix should include at least:

Service	Minimum recovery evidence
2G voice	registration, call setup, call completion, emergency-call success
3G data	attach, authentication, packet-session creation, throughput, congestion
4G data	registration, bearer creation, DNS, Internet and private-network reachability
5G	registration, control-plane stability, session establishment, fallback behaviour
SMS	submit, store, forward, delivery and queue age
Fixed voice	access registration, inbound and outbound calls, emergency routing
Television	live service, authentication, programme data and interactive functions
Enterprise	private gateway, VPN, addressing, routing, policy and application checks
International connections	roaming, interconnect, transit and partner reachability
Customer care	phone, digital channels, account access and status communication

The evidence should be geographically representative and independent from the same control plane being repaired.

If the system that declares service health is part of the compromised environment, a green dashboard is not enough. External probes, partner measurements, synthetic transactions and customer-impact data provide independent views.

Recovery also has stages:

Contained means the damaging action is no longer expanding.
Clean means responders have a trusted administrative environment.
Functionally available means a service can perform a minimum transaction.
Capacity restored means it can carry expected load.
Stable means error rates and dependencies remain within bounds over time.
Remediated means the failure class has been addressed and tested.

Vodafone's statements moved from restoration in progress to network stabilisation. [1][3] The public record does not supply the full service matrix. That is why a recovery account should distinguish operator claims from independently verifiable measurements rather than treating one timestamp as the end of the incident.

Emergency communications turn fallback into a public obligation

Telecommunications outages become public-safety events when users cannot reach emergency services or responders lose operational connectivity.

Ars Technica's contemporaneous report said restoration was being prioritised for emergency services. [14] ANACOM's broader annual incident reporting discusses events that affected access to Portugal's 112 emergency number, although its aggregate figures cannot be assigned entirely to Vodafone. [8]

The evidence boundary matters. The available public record does not establish a complete Vodafone-specific emergency-call failure count. It does establish that emergency-service restoration was a priority and that the outage affected national fixed and mobile communications.

Emergency resilience should be tested as a separate service, not inferred from ordinary voice availability.

A handset may display signal and still fail to complete an emergency call. A network may allow normal calls for registered subscribers while emergency routing behaves differently. Location, call setup, interconnection, public-safety answering points and fallback rules can each fail independently. Devices may behave differently when their home network is unavailable.

An accountable emergency-service record would include:

attempted and completed 112 calls;
setup time and failure cause;
geographic distribution;
device and network-generation class;
routing to the correct answering point;
caller-location availability;
fallback through another layer or network;
public-safety agency connectivity;
time of containment and restoration;
independent validation by authorities.

It should also explain priority.

When capacity is scarce, which traffic is protected? Does the operator reserve resources for emergency calls? Can it limit lower-priority data while preserving voice? Are responders and critical services given managed priority? Do those mechanisms depend on the same policy systems that are damaged?

These are design questions, not post-incident public-relations questions.

The Vodafone sequence suggests the value of restoring basic voice before higher-capacity services. That is a rational service-priority pattern. The public cannot assess its effectiveness fully without service-specific evidence.

The standard should be proportionate transparency: publish enough to show that emergency access was measured and repaired, while protecting details that could create new vulnerabilities.

The management plane can be a larger failure domain than the data plane

Telecom resilience discussions often focus on redundant links, radio sites and data centres. A cyber incident can bypass those physical protections by reaching the management plane.

The management plane includes identities, consoles, orchestration, configuration systems, software repositories, remote access, monitoring and automation. It can change many production systems quickly. That is its operational value and its risk.

A network can have redundant core nodes in separate buildings while both accept commands from the same privileged domain. It can maintain duplicate service platforms while storing their images and configuration in one writable repository. It can have backup links while one policy system controls both.

The public record does not establish that this exact pattern caused Vodafone's outage. It shows why management-plane separation belongs in the accountability test.

An operator should define:

which identities can administer each network generation and service;
whether corporate and network credentials are separated;
how privileged access is approved, recorded and revoked;
whether emergency accounts are protected and tested;
which orchestration systems can change multiple fault domains;
whether configuration repositories are immutable or independently verified;
whether monitoring has a read-only path outside production administration;
whether responders can reach systems through out-of-band management;
how a clean administrative environment is established after compromise.

The recovery process must assume that ordinary tools may be untrustworthy.

If attackers can alter monitoring, responders need external evidence. If they can change configuration repositories, responders need signed or independently hashed known-good state. If they can reach backups, those backups are not recovery assets. If they can manipulate identity, every restored system risks reinfection or unauthorised change.

A clean-room rebuild should have a documented chain:

establish trusted hardware or isolated recovery hosts;
establish trusted identity and credentials;
verify software and configuration provenance;
rebuild minimum control functions;
reconnect one bounded service domain;
measure it independently;
expand capacity and services in controlled stages;
preserve forensic and decision evidence.

Vodafone's statement that national, international and external partner teams worked on recovery is consistent with a complex rebuild. [2][3] It does not reveal the internal method. The accountability requirement is not to publish sensitive commands. It is to prove that restoration did not simply return compromised authority to the same path.

Backups must preserve network state, not only files

"We had backups" is not a complete telecom recovery claim.

Core networks contain several kinds of state:

software images;
configuration;
subscriber and policy data;
keys and certificates;
routing and addressing;
service inventories;
orchestration definitions;
logs and audit records;
dependencies on external platforms.

These assets change at different rates and have different recovery requirements.

A static configuration backup may be clean but too old. A current database copy may include malicious changes. A software image can be authentic while the deployment manifest is wrong. A restored service can function while logging and audit remain incomplete.

The operator therefore needs recovery-point and recovery-time objectives by service, with tests that reconstruct usable network state.

An accountable backup design would answer:

Which state is immutable?
Which copies are offline from production credentials?
How is integrity verified?
How is a known-good time selected?
Which changes after that time must be replayed?
How are keys and certificates restored or rotated?
How are dependencies checked before service activation?
How is restored state compared with intended policy?
How often is a full rebuild exercised?

The Vodafone incident's movement through network generations offers a useful model for staged restoration. Rather than restoring every product at once, an operator can rebuild a minimum trustworthy service and add layers. Each stage should have a signed manifest and measurable acceptance criteria.

That process also produces evidence.

The manifest can bind software hashes, configuration hashes, database snapshots, approvals, deployment targets, start and end times, validation results and residual exceptions. Independent probes can bind service outcomes to the deployed state.

Without this chain, a recovery statement tells customers that service returned. With it, an operator can demonstrate why the restored service deserves trust.

Numbers require definitions

Vodafone Group's annual report said 4.7 million mobile customers and one million fixed-line customers were impacted. [6] RTP reported that four million Portuguese people were affected. [16] These figures are not necessarily contradictory, but they are not interchangeable.

A mobile customer count can represent subscriptions. One person can have multiple SIMs. A fixed-line count can represent households or business lines. An affected service instance does not mean total unavailability for the entire incident. A customer can lose mobile data while retaining voice over 2G. Another can lose television while fixed voice remains available.

ANACOM said 37 security incidents reported in 2022 affected 6.4 million subscribers in aggregate and described one core-network cyberattack as having enormous nationwide impact. [8] The 6.4 million total spans the regulator's incident set; it should not be restated as Vodafone's incident total.

The editorial rule is simple: keep the unit and owner attached to the number.

"Vodafone Group reported 4.7 million mobile customers and one million fixed-line customers affected."
"RTP reported an impact affecting about four million people."
"ANACOM's 2022 aggregate covered 37 incidents and 6.4 million affected subscribers."

Those sentences preserve evidence. "The attack took down service for 6.4 million Vodafone customers" would manufacture a claim the sources do not provide.

The same discipline should govern technical recovery metrics.

An attach-success percentage needs a denominator, geography, generation and time window. A call-completion figure needs destination classes and emergency-call treatment. A service-availability percentage needs a definition of partial degradation. A recovery duration needs a start and a service-specific end condition.

This is not pedantry. Vague metrics can hide concentrated harm.

If national availability is 99 percent but one region has no emergency calls, the average is misleading. If mobile data works for devices that support 3G but not for a fleet of 4G-only enterprise equipment, an aggregate "data restored" claim can hide operational failure.

Good incident evidence makes the denominator visible.

Regulation supplies an evidence framework, not an automatic verdict

At the time of the incident, the European Electronic Communications Code required Member States to ensure that providers took appropriate and proportionate technical and organisational measures to manage risks to network and service security. Article 40 also called for measures to prevent and minimise incident impact and for significant incidents to be notified without undue delay. [19]

ENISA's guidance for Articles 40 and 41 organised controls into domains including governance, systems and facilities, operations, incident management, business continuity, monitoring, auditing and testing. It included examples of evidence an authority or auditor could examine. [18]

These sources are valuable because they move accountability from slogans to controls.

An operator should not only say that security is important. It should show risk ownership, architecture, procedures, tests, monitoring and retained evidence. A regulator should not only count incidents. It should be able to evaluate whether measures were appropriate to the service and risk.

The Vodafone incident can be tested against that framework:

Was core-network risk identified at the service and dependency level?
Were management and production fault domains separated?
Were continuity plans exercised against loss of modern mobile-core functions?
Could teams restore from trusted state?
Were emergency and priority services measured?
Did monitoring remain independent?
Were recovery claims supported by evidence?
Were corrective measures tested?

The available public record does not include an ANACOM decision that answers these questions for Vodafone. It would be wrong to convert the framework into a finding of breach.

Later ENISA reporting aggregated major telecom incidents from 2022, and BEREC's resilience work emphasises continuity of communications during cyberattacks and other disruptions. [9][20] These later sources help explain sector expectations. They do not retroactively prove a specific failure.

The distinction between framework and verdict protects both accuracy and accountability.

It prevents an article from making legal claims without authority. It also prevents an operator from treating absence of a public sanction as proof that every control was adequate. Technical learning can proceed while formal findings remain bounded.

Later architecture announcements are context, not remediation proof

In April 2022, Vodafone Portugal announced that Mavenir would supply a containerised converged 5G core. [5] The timing makes the announcement relevant to the operator's evolving architecture. It does not prove a causal connection to the February incident.

The evidence does not show that Vodafone selected Mavenir because of the attack, that the product replaced the affected system, or that the new core solved the incident's failure class. None of those claims is established by the public sources reviewed here.

The announcement can support a narrower point.

Modern mobile cores are increasingly software-defined, virtualised and orchestrated. Containerisation can improve deployment consistency, scaling and service agility. It also makes software supply, orchestration, identity, policy and observability central to resilience.

A new architecture changes the control surface. It does not remove accountability.

Questions for any converged core include:

Which functions share clusters, identity and orchestration?
How are tenants, network functions and management domains isolated?
Can a configuration or software change cross fault domains?
Are images signed and provenance verified?
Is rollback independent from the primary control plane?
Can a clean core be rebuilt without trusting compromised systems?
How are stateful subscriber and policy functions protected?
What independent probes verify each service after change?

Containerised infrastructure can support immutable deployment and rapid reconstruction. It can also allow one orchestrator to make a broad change quickly. The risk depends on design and control, not the label.

Vodafone's later announcement therefore belongs in the article as an evidence boundary: architecture continued to evolve, but a product announcement is not an incident postmortem or a remediation test.

Regulators need current-byte evidence, not only annual totals

ANACOM's annual reporting is valuable because it places the incident in a sector-wide record. It identified a nationwide core-network event with enormous impact and distinguished malicious causes from other incident classes. [8]

Annual aggregation has limits.

It can show how many incidents were notified, how many subscribers were affected and which causes were common. It cannot, by itself, show whether one operator's segmentation, fallback, backup and restoration controls worked.

For high-impact incidents, a regulator should be able to inspect current-byte evidence:

the approved architecture and dependency map;
access-control and segmentation policy;
effective configuration at the time of failure;
backup and image hashes;
monitoring and alert records;
incident decisions;
restoration manifests;
service-specific test results;
remediation changes;
replay or exercise evidence.

"Current-byte" matters because policy documents can diverge from production.

An operator can have a written segmentation standard while shared credentials still exist. A backup policy can require immutability while a current repository remains writable. A continuity plan can promise fallback while capacity has not been tested since traffic grew.

The evidence chain should bind approved intent to deployed state and observed outcome.

Regulatory access does not require all evidence to become public. Sensitive topology and security details can remain protected. The public can receive a scoped assurance:

what services and dependencies failed;
what control class was changed;
which tests were performed;
who independently reviewed them;
what residual risk remains;
when follow-up verification will occur.

That balance supports trust without advertising vulnerabilities.

Restoration communications are part of operational control

During a national outage, status communication is not separate from resilience. It shapes how customers, emergency services, enterprises and partners respond.

Vodafone used public statements to describe affected services, initial fallback and later stabilisation. [1][2][3] Those statements gave customers a broad recovery picture. The first also acknowledged continuing disruption and ongoing investigation.

An accountable status process should be designed before an incident.

It needs a channel independent from the affected customer-care and production systems. It needs authority to publish bounded facts without waiting for perfect certainty. It needs consistent service definitions and update times.

A useful update says:

what service classes are affected;
when the operator first observed impact;
what remains available;
what fallback customers can use;
which regions or device classes differ;
whether emergency access is affected;
what containment stage has been reached;
when the next update will arrive;
what remains unknown.

It should avoid unsupported attribution and overbroad restoration claims.

The wording "no indication customer data were accessed" is an example of a bounded statement. It communicates current knowledge without claiming a completed investigation. [1]

The wording "network stabilised" should have an internal evidence definition. It might require sustained error rates below a threshold, no unexplained configuration drift, restored monitoring, completed priority-service tests and controlled residual exceptions.

Communication records should become part of the incident ledger. Each statement should be linked to the evidence available at publication time and the decision owner. That allows later review of whether customers received accurate, timely information.

Responsibility follows practical control

The Vodafone Portugal incident involved several actors, but they did not have equal control.

Vodafone Portugal controlled the national network architecture, local operations, service restoration, fallback activation, monitoring and customer communication. It controlled which systems shared identity and management, how backups were protected, which services received priority and what evidence supported recovery.

Vodafone Group may have provided shared security, platforms, expertise and governance. Vodafone's statements referred to national and international teams. [2][3] The public record does not disclose the precise split, so it does not support assigning a specific action to the Group.

External partners and suppliers may have supported technology and recovery. Their contractual authority and access are not public. Supplier involvement does not remove the operator's accountability for integration, access boundaries and continuity.

ANACOM controlled sector oversight, notification and evidence requests. It did not operate Vodafone's production systems.

CNCS and other national authorities supplied cybersecurity coordination, investigation or context. They did not design Vodafone's service dependencies.

Emergency services, enterprise customers, interconnecting operators and roaming partners controlled their own continuity and external measurements. They depended on Vodafone's network and could provide impact evidence, but they could not repair the core.

The attacker controlled the malicious actions available through whatever access was obtained. The public record does not establish who that was or how much access they had.

This map prevents responsibility from collapsing into one word.

An attacker can cause the incident and an operator can still be accountable for resilience. A supplier can provide a platform and the operator can still be accountable for fault-domain design. A regulator can oversee the sector without becoming responsible for production recovery. Customers can maintain backups without being able to compensate for national mobile-core loss.

The strongest accountability claim is attached to a practical control:

who could prevent shared access;
who could isolate a service;
who could activate fallback;
who could restore trusted state;
who could validate service;
who could communicate;
who could require remediation evidence.

Accountability should not become personal blame

The public record does not identify an employee, administrator or executive whose decision caused the outage. No individual should be inferred.

Even when a major incident begins with one credential or one command, the scale of harm reflects a system.

Organisations choose:

how privilege is granted;
whether access is segmented;
whether changes require review;
whether backups are independently protected;
whether monitoring can be altered by production administrators;
whether fallback capacity is tested;
whether responders have clean tools;
whether service restoration has measurable gates.

Leadership controls funding, staffing, maintenance windows, architecture priorities and the authority to stop risky work. Engineering teams control implementation within those conditions. Suppliers control product features and support within contracts. Regulators control oversight and evidence demands.

Focusing on one person can hide these choices. It can also discourage reporting and reduce learning.

A better review asks:

Which control should have limited initial access?
Which control should have limited lateral authority?
Which control should have protected recovery state?
Which fallback worked?
Which fallback lacked capacity or coverage?
Which independent monitor detected service health?
Which owner could authorise containment?
Which evidence proves remediation?

These questions can identify responsibility without claiming motive or negligence.

They also recognise successful controls. The ability to restore 2G voice and 3G data before modern services suggests that some diversity and recovery capability remained. The lesson is not that everything failed. It is that resilience must be measured at each surviving and failed boundary.

Customers need evidence proportionate to dependence

Most customers cannot inspect a mobile operator's core. They can still demand useful evidence.

A consumer needs accurate service status, emergency-call guidance, fallback instructions, data-compromise updates and fair handling of prolonged loss.

An enterprise needs more:

which access and gateway services were affected;
whether private addressing and routing changed;
whether authentication or certificates changed;
whether managed security remained active;
whether international links and roaming worked;
which transactions failed;
how restoration was validated;
what remediation affects its own continuity plan.

A public agency or critical service may need contractual evidence of priority, diversity and independent recovery.

The incident also challenges assumptions about backup connectivity.

Two retail products can depend on the same operator core. A fixed link and mobile backup can share identity, transport, DNS, support or management systems. A second SIM can use the same network. A roaming arrangement may still depend on the home operator for authentication or policy.

Continuity testing should therefore follow dependency, not product name.

Customers can ask:

Is backup connectivity on a genuinely separate operator and core?
Does it use separate power, access, transport and DNS?
Can users authenticate if the primary identity system fails?
Can critical applications tolerate lower-bandwidth 3G or basic voice?
Are emergency and incident contacts available outside the primary network?
Are failover exercises conducted under realistic congestion?

These questions do not transfer operator responsibility to customers. They recognise that critical services must understand concentration they can control while operators remain accountable for the infrastructure they sell.

What a verifiable remediation package would contain

Restoration ends immediate harm. Remediation addresses recurrence.

A verifiable remediation package for this event class would not need to expose exploitable detail. It would need to connect failure, control and test.

1. Fixed event boundary
Identify affected service and control domains, time windows, regions and customer classes. Preserve the distinction between confirmed facts, operator attribution and unknowns.

2. Authority map
Show which identities, systems and teams could change each domain. Identify common administrative paths and exceptional access.

3. Dependency map
Bind mobile generations, fixed services, television, messaging, customer care, enterprise and international functions to shared and independent components.

4. Recovery-state provenance
Record software, configuration, subscriber and policy state used for each rebuild, with hashes and trust decisions.

5. Service restoration matrix
Report functional and capacity tests for each service, region, generation and priority class.

6. Independent observation
Use probes and partners outside the restored control plane to validate reachability and transactions.

7. Corrective controls
Describe the class of segmentation, access, backup, monitoring or process change made.

8. Replay testing
Exercise the original failure class and semantic variants in a controlled environment.

9. Residual risk
State dependencies that remain shared, exceptions accepted and milestones still open.

10. Independent assurance
Record who reviewed the remediation, what evidence they saw and what limitations remained.

The package should be bound to the exact deployed version. A report that references a policy without binding the deployed configuration cannot prove production state. A screenshot of a green dashboard cannot prove independent service. A statement that backups exist cannot prove clean recovery.

Evidence quality should match blast radius.

For a system capable of interrupting millions of subscriptions and national services, the repair record should survive leadership turnover, supplier change and the next incident.

What the public record cannot prove

The public record reviewed here supports a strong network-accountability analysis and a bounded conclusion. It does not support a complete technical postmortem.

It cannot prove:

the attacker;
the attack vector;
malware or ransomware;
the first compromised identity or device;
the exact core or management systems affected;
the amount or type of data destroyed;
whether customer data was accessed after the first statement;
the precise detection and containment times;
the internal topology;
segmentation and privilege state;
backup integrity;
clean-room procedures;
service-by-service impact;
complete emergency-call impact;
roaming and enterprise impact;
individual decisions;
contracts or losses;
a regulator finding;
the exact remediation deployed.

It also cannot prove that later architecture changes were caused by the incident. Vodafone's April 2022 Mavenir announcement is context, not a repair certificate. [5]

Later ENISA, GSMA and BEREC materials provide sector lessons, but they should not be used to rewrite what was required, known or implemented on 7 February 2022. [9][13][20]

These limits do not weaken the central conclusion.

The public chronology shows a maliciously triggered communications failure with broad service coupling and staged fallback. That is enough to identify the controls that matter: isolation, recovery state, legacy capacity, priority, measurement and evidence.

The unknowns define what an accountable postmortem should supply.

A reusable core-network resilience accountability test

The incident supports a practical test for any national communications operator.

1. Map shared authority.
Identify identities, management systems, orchestration and repositories that can change multiple service domains.

2. Define fault domains.
Document which mobile generations, fixed services, messaging, television, enterprise and support platforms can fail independently.

3. Separate management paths.
Ensure a compromise of ordinary corporate or production administration cannot control every network and recovery layer.

4. Protect known-good state.
Maintain independently verified software, configuration, keys and essential service data outside production authority.

5. Design a clean recovery environment.
Provide trusted identity, tools, communications and out-of-band access before an incident.

6. Preserve fallback capacity.
Measure what older generations or alternate cores can carry by region, device and service class.

7. Prioritise essential communications.
Define emergency calls, public-safety users and critical services, and test priority under constrained capacity.

8. Restore in bounded stages.
Activate one service domain at a time with signed manifests, acceptance tests and rollback.

9. Measure from outside.
Use independent probes, interconnecting operators and service transactions not controlled by the restored environment.

10. Define restoration precisely.
Separate containment, functional availability, capacity, stability and remediation.

11. Preserve decisions and evidence.
Bind alerts, approvals, deployed bytes, service measurements, public statements and exceptions.

12. Test the failure class.
Exercise loss or compromise of the management and core domains, not only ordinary equipment failure.

13. Audit dependency retirement.
When 2G, 3G or another fallback is removed, prove the replacement continuity function.

14. Publish proportionate assurance.
Tell customers and regulators what failed, what changed, how it was tested and what remains uncertain without exposing attack-enabling detail.

This test does not promise uninterrupted service. It makes control and evidence commensurate with the reach of the network.

Conclusion

Vodafone Portugal's 2022 disruption showed that telecom resilience is visible in the order services return.

The operator reported a deliberate malicious cyberattack. 4G and 5G, fixed voice, television, SMS, customer-service functions and business applications were affected. Mobile voice and 3G data returned before modern mobile generations. Teams then restored 4G and 5G and continued stabilising the broader service set. [1][3][6][7]

The public record does not identify the attacker, vector or exact damaged systems. It should not be stretched into an unsupported forensic or legal conclusion.

It does identify the infrastructure questions.

Why could one event affect so many services? Which core and management dependencies were shared? What authority was segmented? Which recovery state remained trustworthy? How much traffic could legacy layers carry? How were emergency and enterprise services measured? What proved that restoration was stable and remediation durable?

Accountability does not mean blaming an operator for being attacked. It means evaluating the controls the operator actually possessed after prevention failed.

The 2G and 3G fallback deserves to be treated as a working resilience control. The broad outage deserves to be treated as evidence of correlated dependency. The less-than-24-hour restoration claim deserves service-specific measurement. The later stabilisation deserves a distinction from complete remediation.

For national communications infrastructure, "service returned" is the beginning of the evidence duty, not its end.

Vodafone Portugal's 2022 Core-Network Recovery Made Telecom Resilience Evidence an Accountability Test