NIS2 arrived in Bulgaria with no grace period: a checklist for fuel retailers and their software suppliers

Bulgaria transposed the NIS2 directive sixteen months late and then all at once. Parliament adopted the amendments to the Cybersecurity Act on 5 February 2026, they entered into force in mid February, and the law provides no transitional compliance period. The only concession was reduced sanctions for breaches committed before 1 June 2026. That window has closed. For essential entities the ceiling is now EUR 10 million or 2% of worldwide turnover, whichever is higher, and management can be held personally accountable for failing to approve and oversee the measures.

Why this matters to a fuel retailer: the sectoral annexes follow NIS2, and energy, including the supply and distribution of petroleum products, is an Annex I sector. The size test is the general one: medium-sized enterprises and above, meaning fifty or more employees or EUR 10 million turnover. A chain of fifteen staffed stations clears the headcount test on cashiers alone. Most independent networks we work with are in scope as important entities; the larger integrated ones as essential. And because the law obliges in-scope entities to manage supply chain risk, it reaches their software vendors by contract even where it does not reach them directly.

What the law actually asks for

The obligations are the ten NIS2 measure areas, written into the Act: risk analysis and security policies, incident handling, business continuity and backup, supply chain security, secure acquisition and development, effectiveness assessment, cyber hygiene and training, cryptography, access control and asset management, and multi-factor authentication where appropriate. Plus registration with the competent authority and incident reporting on the NIS2 clock: an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within one month.

Translated to a forecourt, that abstract list becomes something quite specific.

The forecourt threat model

A station is a small industrial site with a retail shop bolted on. The assets that matter are the forecourt controller and its serial or IP links to dispensers and tank gauges, the POS and back office machines, the fiscal device, the payment terminal, the site router with its LTE fallback, the head office replication channel and, increasingly, EV chargers and a CCTV system on the same network. Three things make it different from an office: half the devices cannot run endpoint security, the site operates unattended networks at night, and an attacker who can issue dispenser commands has a physical safety problem, not just a data one.

A checklist that survives an audit

• Asset inventory per site. Every device with an IP or serial address, firmware version, owner, and whether it can be patched. Our head office already polls dispenser and fiscal device versions for price and euro audits; the same data is the NIS2 asset register, exported.
• Network segmentation. Forecourt control, payment, fiscal, CCTV and guest Wi-Fi on separate VLANs with the site router as the only crossing point. The dispenser segment should never route to the internet; the controller talks to head office through a broker, not the other way round.
• Access control on service interfaces. Fiscal devices are opened with a service key held by technicians registered with the revenue agency; dispensers have maintenance modes; controllers have vendor accounts. All of these need named users, logged sessions and removal when the technician leaves. Shared vendor passwords across a network are the single finding we see most often.
• MFA for head office and remote access. The back office web application and any VPN into a site. Cashier logins on the POS are a different matter; there, a card or PIN and a shift record are the proportionate control.
• Patching with a schedule you can show. Operating systems on POS and back office machines, the controller firmware, the router. For devices that cannot be patched, a documented compensating control, usually segmentation.
• Backups that have been restored. The local station database and the head office database, with a restore test recorded. An offline first architecture helps here: a station keeps selling on its local database while head office is rebuilt, which is the continuity plan written down.
• Logging and an incident procedure. Router, controller, POS and back office logs shipped to a central store with retention, and a one page procedure naming who decides that an incident is significant, who files the 24 hour early warning, and where the template is.
• Supplier clauses. Contracts with the POS vendor, the fiscal service company, the payment provider and the telecom operator covering security obligations, vulnerability disclosure and notification of incidents on their side.
• Management sign-off and training. The measures approved by the managing body, with the training the Act requires for them recorded.

What we changed on our side

As a supplier we cannot make a customer compliant, but we can stop being the weak link. Over the last two quarters we published a security statement for the station POS and head office platform, moved all vendor access to named accounts with hardware MFA and session recording, added signed releases with a software bill of materials, and built the per site asset and version export mentioned above. We also committed to a vulnerability disclosure address and to notifying customers of incidents on our side within the timelines they need to meet theirs. None of it is exotic; all of it is now being asked for in tenders.

If you run a station network and have not yet registered with the competent authority, that is the first step. The rest of the list takes a quarter to do properly, and most of it improves uptime before it improves compliance.