Ireland Is Being Taken to Court Over NIS2. 88% of the Security Vendor Detections We Found Were American.

Ireland took over the rotating Presidency of the Council of the EU on 1 July 2026. A week later, on 8 July 2026, the European Commission referred Ireland to the Court of Justice of the EU, along with Spain, France, and the Netherlands, for failing to notify full transposition of the NIS2 cybersecurity directive. The deadline had been 17 October 2024. Most of the EU's 27 member states missed it too, 23 of 27 hadn't transposed on time, but by mid-2026, after a formal notice in November 2024 and a reasoned opinion in May 2025, most had closed the gap. These four hadn't, and are the ones the Commission has now escalated to court, seeking financial penalties. Ireland now chairs the same cybersecurity and digital sovereignty agenda its own government is late implementing.

Against that backdrop, we externally fingerprinted the security and access-control vendors visible on organisations in our Irish dataset, to see whose technology actually shows up at the perimeter.

We recorded 119 security and authentication vendor detections across 81 of the 310 organisations in our sample, one detection per vendor per organisation: 88.2% trace to a US-headquartered ultimate parent, 8.4% to a single Danish company, 2.5% to a company now owned by a French parent, and 0.8% to one owned by a Dutch private equity firm. These are detection counts, not a share of the 310 organisations: most of the sample had no security or auth-category vendor visible to our fingerprinting at all.

Snyk, the vendor at the centre of the AIB controversy that prompted this question, doesn't appear anywhere in this data, and can't: it's a developer-tooling product used in CI/CD pipelines, not something visible on a public website, VPN portal, or DNS record. We have no direct observation of Snyk deployment at AIB or anywhere else in this sample. What we can measure is external vendor concentration, a narrower question than which vendor a company has actually contracted with.

What we measured

For each of the 310 organisations, we ran DNS-based subdomain discovery, then fingerprinted the primary domain and any discovered subdomains classified as login, SSO, admin, dashboard, or VPN/remote-access surfaces. Matches come from HTTP response headers, page titles, response body markers, and MX records, checked against a fixed set of vendor signatures. This identifies a vendor only if we hold a signature for it and the surface is internet-reachable; a firewall management console sitting behind a client VPN, for example, is invisible to this method regardless of whether it exists.

Vendor sovereignty, by current parent company

We classify each vendor by its current ultimate parent company's headquarters, not by where it was founded or where its own headquarters happens to sit if a parent company owns it. A vendor founded in one country and later acquired by a company headquartered in another is classified under the acquirer. Founding country is mentioned separately where it adds real context.

The Denmark figure is Cybot, trading as Cookiebot, a genuinely Danish-headquartered independent company. Its product is cookie-consent management, not a firewall, IAM platform, or VPN gateway; it sits in this chart because our fingerprint rule set files privacy tooling under the same category as security tooling, alongside OneTrust (also consent management, US-owned) and TrustArc (also consent management, now owned by Main Capital Partners of the Netherlands). Consent-management tooling accounts for 37 of the 119 detections here, a real EU data point, but not what most readers picture when they think "security infrastructure."

The France figure is entirely Imperva, a web application firewall vendor founded in Israel in 2002, listed on the NYSE in 2011, bought by Thoma Bravo (US private equity) in 2019, and bought again by Thales, the French defence and technology group, in 2023. Its current parent is French; its founding country is Israeli.

A second category-label issue: 9 of the 119 detections are Akamai, tagged "security" in our rule set on the strength of the X-Akamai-Transformed response header. That header only confirms traffic passed through Akamai's CDN edge; our rule set has no signature that distinguishes a WAF-enabled Akamai deployment from a plain CDN one, so these 9 detections prove Akamai CDN usage, not Akamai WAF usage. They're included in the top-line count above because that's what our rule set currently labels them, but they don't belong in the narrower firewall/WAF/IAM/VPN subset below.

The narrower number: core firewall, WAF, IAM, and VPN vendors

The chart above includes consent management, bot detection, and email security alongside firewalls and access control, because that's how our fingerprint rules categorise them, and it includes Akamai's CDN-only detections under a "security" label that doesn't hold up on inspection. Restricting to detections where the matched product is genuinely a firewall, WAF, IAM platform, or VPN/remote-access gateway, and where the specific match corresponds to that function rather than another product from the same vendor, leaves 15 detections across 13 organisations: Sucuri Firewall (4), Microsoft Azure AD/Entra ID (4, counted once per organisation), Imperva WAF (3), Citrix NetScaler ADC (2), F5 BIG-IP APM (1), Okta (1). Both Barracuda detections in this sample were matched via an MX record identifying its email security product, not its separate SSL-VPN product, so they're excluded here even though Barracuda also sells VPN appliances.

Fifteen detections is a small base; a single organisation switching vendors would move the split by several points, so treat this as "12 detections versus 3," not a stable population estimate. The pattern worth taking from it is that no independently EU-founded and EU-owned vendor appears at all. The only non-US result is Imperva, EU-parented by a 2023 acquisition rather than by a European company having built the product.

Separately: no detection in this sample matched our fingerprint rules for Check Point or CyberArk, two well-known Israeli-founded cybersecurity vendors. We looked for both specifically, including after fixing a gap in our own tooling that had been skipping VPN and remote-access-classified subdomains, the exact surface where a Check Point Mobile Access portal would be visible. The fix recovered real detections for Citrix, Barracuda, and F5 that an earlier pass had missed; it still didn't surface Check Point or CyberArk anywhere in this sample. External scanning alone can't tell us whether that means low adoption, or that both vendors' Irish deployments tend to sit behind access controls, a client VPN or IP allowlisting, that keep them outside what a scan can reach. A zero result here is a finding about what we could observe, not about what's deployed.

Full vendor breakdown

All 119 security/auth-category detections, by vendor. Each row is a distinct organisation count, one detection per vendor per organisation:

Three of Microsoft's four detections showed both the Azure AD and Entra ID product signature on the same organisation (Entra ID is Microsoft's current name for the same identity platform); that organisation is counted once, not twice, in the vendor total.

A secondary finding: email-authentication hygiene

Separately from vendor origin, we checked DMARC, SPF, and DKIM on the same 310 domains, a narrower question of whether organisations have configured controls they already have, independent of vendor choice. This isn't a NIS2 compliance measurement; DMARC isn't named by name in the directive.

SPF and DMARC are single published DNS TXT records. DKIM is harder to check externally: its key lives at a selector-specific subdomain chosen by whoever configured mail, not a fixed location, so we looked up twelve common selector names (default, google, mail, and others) and counted DKIM present if any resolved. That catches predictable setups and misses custom ones, so 50.0% is a floor, not a precise figure.

The gap worth noting is between SPF (80.0%) and enforcing DMARC (44.2%). SPF is published through a single DNS TXT record; an enforcing DMARC policy requires confidence that every legitimate mail source authenticates and aligns correctly first, since a wrong move starts blocking real mail. DMARC also checks alignment, not just presence, and we measured published policy rather than alignment behaviour in production, so 44.2% is an upper bound. The pattern is consistent with many organisations starting a DMARC rollout and stopping at p=none, monitor-only.

Getting from p=none to p=reject without blocking your own mail is the actual work. SenderLedger is built for that, not for another pie chart.

Method note

Sample: 322 organisations tracked in CipherCue's Irish dataset, drawn from three sources: the ISEQ 20 (Euronext Dublin), a curated list of Irish-founded technology companies and EMEA-headquartered multinationals with a Dublin presence, and a sample of 165 active PLC, DAC, and CLG companies drawn from Ireland's Companies Registration Office Open Data Portal (opendata.cro.ie, CC BY 4.0 licence), matched to a domain via name-derived candidate generation and DNS resolution. 310 of the 322 organisations returned usable fingerprint and DNS compliance data. This is a sample of organisations operating in or registered in Ireland, not a census, and should not be read as a statement about all of Ireland's infrastructure.

Vendor fingerprinting: we probe each organisation's primary domain plus any discovered subdomain classified as a login, SSO, admin, dashboard, or remote-access surface, and match the response against a fixed set of vendor signatures (HTTP headers, page titles, response body markers, MX records). This identifies a vendor only if we hold a signature for it and the surface is internet-reachable; backend-only infrastructure with no internet-facing component is not observable by this method.

Sovereignty classification: vendors are classified by current ultimate parent-company headquarters, verified individually against public acquisition and ownership records at the time of writing, not by an automated database and not by founding country. Where founding country differs from current ownership, both are stated in the text.

Core subset: the firewall/WAF/IAM/VPN figure includes only detections where the matched product itself is one of those four categories. A vendor that sells more than one product type (Barracuda sells both email security and SSL-VPN appliances) is only included when the specific detection matched its firewall, WAF, IAM, or VPN product; detections matched via other signals (an MX record identifying an email security product, for instance) are excluded even for vendors that also sell relevant infrastructure elsewhere. Akamai's 9 detections are excluded from this subset: our rule set tags them "security" on the strength of a CDN response header (X-Akamai-Transformed) that says nothing about whether a WAF module is active, so they don't meet the bar of a confirmed firewall or WAF match.

DMARC/SPF: checked via direct DNS TXT record lookup against each organisation's primary domain. DKIM: checked via lookup at selector._domainkey.domain for a fixed list of twelve common selector names; DKIM can only be confirmed present when one of those selectors is in use, so the true adoption rate may be higher than reported. "DMARC enforcing" means a published policy of p=quarantine or p=reject. This section measures a general email-authentication and cyber-hygiene signal; it is not a NIS2 compliance measurement, and DMARC is not named by name in the directive's requirements.

NIS2 referral: drawn from the European Commission's press release of 8 July 2026 (ec.europa.eu/commission/presscorner, reference IP/26/1499).

Finding this in your own market

CipherCue tracks externally observable security and infrastructure vendor prevalence by country, industry, and company, filterable the same way for any market we cover.