← Back to the cybersecurity blog

Adif and Renfe cyberattack: what we know and why the link between their systems matters

By Thilina Manana · COO, Director Técnico de Seguridad hard2bit y socio fundador · Published: 27 September 2026 · Updated: 27 September 2026
Adif and Renfe cyberattack AI-generated image

Late on Thursday 24 September, Adif, the state company that manages Spain's rail infrastructure, detected "unusual activity" on its systems. The next day Renfe, the national train operator, said attackers had used previously compromised Adif servers that were interconnected with Renfe's systems to reach customer information, mainly names and email addresses.

Neither organisation has reported any effect on train services. Adif took the Adif and Adif Alta Velocidad websites offline as a precaution and brought them back on Saturday 26 September, lodged a criminal complaint and notified Spain's National Cryptologic Centre (CCN). Renfe isolated the affected environments, activated its response protocols and called in independent specialists.

For other organisations, the telling detail is the origin. By Renfe's account, the intrusion that exposed its customer data began inside another organisation's systems, which were connected to Renfe's by design. MITRE ATT&CK catalogues that route as Trusted Relationship (T1199), and companies that exchange data, accounts or access with a partner, a supplier or a subsidiary are exposed to it.

What have Adif and Renfe confirmed?

As of 27 September, the two organisations have publicly confirmed the following:

  1. Detection: unusual activity on Adif's systems late on Thursday 24 September.
  2. Origin: Adif servers compromised at some earlier point and interconnected with Renfe systems.
  3. Data: a "limited" volume of Renfe customer information, mostly names and email addresses, with no sign of access to bank details, payment methods or national ID numbers.
  4. Publication: Renfe has found no conclusive evidence that the information has been released.
  5. Background: Renfe had been blocking repeated attack attempts for several weeks beforehand.
  6. Rail operations: according to Adif, no system involved in running the railway was affected.
  7. Notifications: Adif lodged a complaint, informed the CCN and alerted companies and suppliers that may have been affected.

Were 500 GB stolen and was AI used? What remains unconfirmed

Two claims have driven much of the coverage without official backing. The first is volume. El Mundo, quoting sources close to the investigation as reported by Infobae, put the haul at around 500 GB taken, with the peak on the Thursday. It also named Adif's website as the possible entry point, from where the attackers are said to have moved into Adif's cloud environment and then into Renfe.

The second is artificial intelligence. According to the same sources, investigators are examining whether the attackers used an AI system to find the weakness they exploited. Neither organisation has confirmed this or the 500 GB figure, and the group behind the attack has not been identified.

The two accounts are hard to reconcile. A list of names and email addresses, even for millions of passengers, takes up a tiny fraction of 500 GB. If that figure holds, more data was taken than the customer records Renfe has described, and nobody has yet said what it was or which systems it came from. Until Adif or Renfe say more, this analysis works from what is confirmed and treats the rest as unproven.

How does an attacker move from one organisation into a connected one?

Adif and Renfe were both part of the old RENFE until 1 January 2005. That day, the split between infrastructure management and train operations set out in Spain's 2003 Railway Sector Act (Law 39/2003) took effect. Today Renfe runs its trains on the network Adif manages, and the two exchange information every day. Each of those exchanges rests on a technical mechanism: a service account, an API, a network tunnel, a shared folder or a replicated database.

Whoever controls one end of such a link inherits the trust the other end extends. Many organisations scrutinise traffic arriving from the internet yet treat a partner's traffic as internal, with broad permissions and light monitoring. An attacker can come through that gap without ever breaching the second target's perimeter.

Rail is no special case. ENISA's Threat Landscape 2026 notes that criminal groups are increasingly going after suppliers and third parties, as we covered in our reading of the report without the DDoS noise. Verizon's 2026 Data Breach Investigations Report finds a third party involved in 48% of the breaches it analysed, a broad category that goes well beyond trusted-relationship intrusions.

What does Spain's ENS require for system interconnection?

Adif and the Renfe group belong to Spain's state public sector, which places them within the scope of the National Security Framework (ENS). The framework covers this situation in measure op.ext.4 of Royal Decree 311/2022, "Interconnection of systems", which applies to medium- and high-category systems.

The measure requires prior authorisation for any exchange with other systems and prohibits every information flow that has not been expressly authorised. Each interconnection must be documented, covering the characteristics of the interface, the security and data protection requirements, and the nature of the information exchanged. At the high category it adds enhancement R1, on coordination of activities, which fits cases like this one. Where identification, authentication and authorisation take place in different security domains under different owners, local measures must come with coordination mechanisms that assign each party its responsibilities.

Article 33(2) of the same decree requires public sector bodies to report incidents with significant impact to the CCN, and Adif has informed the CCN of this one. Under Article 2(3), the ENS also covers the systems of private companies that, under contract, provide services or solutions that public bodies use to exercise their powers.

For the rest of the private sector, the nearest references are the supplier relationship controls in ISO/IEC 27001:2022 (5.19 to 5.22), which are voluntary, and the supply chain security required under Article 21 of NIS2. Spain had yet to transpose that directive as of 27 September, while Royal Decree-Law 12/2018, which implemented the first NIS Directive, remains in force.

How exposed are customers if only names and emails leaked?

A name tied to an email address and to the fact of being a Renfe customer is enough to build a convincing phishing email. The obvious lures are refunds linked to the incident itself, compensation for delays, ticket changes or requests to "verify your account". Anyone receiving such a message should open the Renfe app or type the website address themselves, and leave the link alone.

Employers are exposed too. Plenty of staff book business trips with their work email, so the list may hold corporate addresses next to the full names of people who probably travel for work. That is useful material for spear phishing aimed at the employer, and a good reason for an internal heads-up to frequent travellers.

As for Renfe's obligations as data controller, Article 33 of the GDPR requires a breach to be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. The exception is a breach that is unlikely to result in a risk to individuals. Article 34 adds, as a rule, direct communication to those affected when the risk is high. How this case is assessed will depend on what the investigation confirms about the volume and type of data.

Five checks for organisations connected to others

Start with an inventory of interconnections: which outside organisations can open a connection into your systems, with which account, over which protocol and which data they can reach. Without that inventory, the other measures rest on an incomplete picture.

Next, treat each partner as a network zone of its own, with access limited to the systems it needs and service accounts holding the fewest permissions possible. It is the same reasoning we set out in our piece on internal network segmentation, applied at the border with another organisation.

Then watch what leaves. A large extraction spread over several days leaves traces in network flows, firewall logs and cloud egress billing. Spotting it depends on those sources feeding a SOC that correlates them, and our guide on which logs to send to a SIEM helps set priorities.

Read blocked attempts as a warning, too. When they keep hitting the same services for weeks, someone has usually picked the organisation as a target, and that is the moment to review its attack surface and that of the entities it is connected to, starting with web applications.

Finally, agree in writing what happens when the other side is compromised. Contracts and interconnection agreements should set notification deadlines, incident response contacts and who has the authority to cut the link, and the procedure should be rehearsed before an incident. Third-party risk management and an incident response plan shared between organisations give those agreements a framework.

Renfe's statement and the line that looked AI-written

Renfe's statement has a sound structure: which data was affected, which was not, what action has been taken and what is still under investigation. According to ADSLZone and Que.es, the first version posted on its website ended with the sentence "Esta segunda versión tiene un tono más institucional" ("this second version has a more institutional tone"), which both outlets read as a leftover from AI-assisted drafting. By the time they published, the text had been corrected.

The episode reflects a common risk in the first hours of any incident, when texts are written in a hurry, pass through many hands and go out with fewer checks than usual. Pre-approved templates and a final human read before publication make it less likely that a slip of form overshadows the message, as our guide to crisis communication in the first 24 hours explains.

Open questions, and one for the board

Still unanswered: how much was taken and what it contained, whether AI played any part, who is behind the attack and whether the data will surface on a forum. We will update this analysis as Adif, Renfe or investigators release new information.

The question for the next board meeting is which outside organisations can reach your systems today, with which credentials and how far. If the answer is not written down, the interconnection inventory is the first job.

This analysis is based on public statements by Adif and Renfe and on reporting by the outlets cited, up to 27 September 2026. The volume figures, the reported entry route through Adif's website and cloud, and the possible use of artificial intelligence come from press reports and have not been confirmed by the organisations affected. It does not attribute the incident to a flaw in any particular product or technology vendor, and attribution of the attack may change as the investigation proceeds.

Frequently asked questions

What data was exposed in the Renfe cyberattack? ▾

According to Renfe, the attackers reached a limited volume of customer information, mainly names and email addresses. The company says there is no sign of access to bank details, payment methods or national ID numbers, and it has found no conclusive proof that the information has been published.

Did the Adif and Renfe cyberattack disrupt train services? ▾

According to Adif, no. It says no system involved in running the railway was affected and trains ran normally. What did go offline, as a precaution, were the Adif and Adif Alta Velocidad websites, which were back up on Saturday 26 September.

Were 500 GB really stolen in the Adif and Renfe cyberattack, and was AI involved? ▾

Both claims come from sources close to the investigation quoted by El Mundo and have not been confirmed by Adif or Renfe. If the 500 GB figure is borne out, it would mean far more information left than the names and email addresses described, since a list like that takes up very little space; what that information was, and which systems it came from, is unknown. On AI, investigators are examining whether it was used, and no verifiable detail has emerged so far.

I am a Renfe customer. What should I do? ▾

Over the coming weeks, be wary of any email or text message that uses the Renfe brand to offer refunds, compensation or ticket changes, or asks you to verify your account. For anything you need to do, open the app or type the website address yourself. In Spain, INCIBE's 017 helpline offers free advice on suspicious messages.

What is an attack through a trusted relationship? ▾

It is one that reaches an organisation from another it is legitimately connected to, such as a partner, supplier or subsidiary. The attacker first compromises the more accessible party, then uses the accounts, links or permissions the target grants that party to get in without breaching the target's perimeter. MITRE ATT&CK lists it as technique T1199.

What does the GDPR require after a breach like this? ▾

The controller must report the breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to individuals. A later notification must give reasons for the delay. Where the risk is high, the people affected must as a rule also be told directly, subject to the exceptions in Article 34(3). The assessment turns on the type and volume of data involved.

How can a company reduce the risk of being attacked through a connected organisation? ▾

With an inventory of every external connection and why it exists, a separate network segment for each partner, service accounts with minimal permissions, monitoring of outbound traffic and written agreements setting notification deadlines and who may cut the link. In Spain's public sector, ENS measure op.ext.4 requires every interconnection in medium- and high-category systems to be authorised and documented.

Want to know what's actually exposed, and what to fix first?

Thirty minutes with a technical consultant — not a salesperson — is enough to get the problem in order: what's exposed right now, what gets fixed this week, what can wait, and what each stage costs. Penetration testing, security audits, vulnerability management, Microsoft 365, SOC/MDR and incident response.

If your situation is different, tell us anyway — we also take one-off questions on cybersecurity and regulatory compliance.

Based in Spain · Working across the EU and LATAM · ENS High · ISO 27001 · We usually reply in under 24 business hours