The Dark Army

Category: Tech News

  • How DVLA’s Vehicle Data APIs Are Being Scraped and Abused: The Hidden Attack Surface Behind UK Number Plate Lookups

    The DVLA sits on one of the most queried public datasets in the UK. Every day, millions of number plate lookups happen across insurance comparison sites, parking enforcement systems, ANPR cameras, and just plain-curious members of the public using the free vehicle enquiry service at gov.uk/check-if-a-vehicle-is-taxed. What most people don’t think about is that the same infrastructure sitting behind that friendly web form is also being quietly harvested by OSINT operators, fleet data aggregators, and outright fraudsters running bulk scraping scripts. DVLA vehicle data scraping is not a new problem, but in 2026 it has become trivially easy in ways that deserve a proper technical breakdown.

    What the DVLA actually exposes publicly

    The primary public interface is the Vehicle Enquiry Service (VES). Submit a valid UK registration mark and it returns tax status, MOT expiry, make, colour, engine size, fuel type, and date of first registration. No authentication. No CAPTCHA on the API endpoint itself. Just a POST request with a VRM and you get JSON back.

    There’s also the official DVLA Vehicle Enquiry API, documented on the DVLA’s developer pages and technically rate-limited, which third parties can apply to use programmatically. The official API requires an API key and is intended for legitimate businesses. MOT history is available separately via the DVSA (Driver and Vehicle Standards Agency) MOT History API. Between VES, the DVLA API, and the DVSA endpoint, you can build a reasonably rich picture of any registered vehicle in Great Britain from public data alone.

    The problem is that public doesn’t mean protected. The web-facing VES form is backed by calls to an API endpoint at https://driver-vehicle-licensing.api.gov.uk/vehicle-enquiry/v1/vehicles. That endpoint requires an x-api-key header for direct calls, but the web form itself proxies requests through DVLA’s own backend, which means the browser is making a request to a DVLA-controlled intermediary rather than the API directly. That intermediary is where the interesting attack surface lives.

    How bulk scraping actually works against VES

    UK number plates follow a predictable format. Post-2001 plates are two letters (area code), two digits (year), then three random letters. The total keyspace for any given half-year cohort is 26x26x26 letters at the end, which is 17,576 combinations, multiplied by however many area codes and year codes are valid. A motivated scraper can enumerate a specific year’s registrations methodically, or use known partial plates to target specific regions or vehicle ages.

    Scripts doing this aren’t sophisticated. A basic Python script with requests and a rotating proxy pool can hammer VES through the web form pathway. Rate limiting on the public-facing web service has historically been lenient enough that a few hundred requests per IP per hour go unnoticed. Distribute that across a handful of residential proxy IPs and you’re pulling tens of thousands of records daily without triggering anything visible.

    The responses are clean JSON through the browser’s network tab, which means you don’t even need to parse HTML. Open DevTools on the VES page, inspect the XHR requests, and you have your payload structure in under two minutes. I’ve watched people do this live in Discord servers as a casual exercise. The barrier to entry is basically zero.

    For OSINT practitioners this is a legitimate and legal activity in many contexts. Checking whether a vehicle at a specific address is taxed and MOT’d is not illegal. Aggregating VRMs at scale to build commercial datasets without authorisation from the DVLA is a different matter entirely, sitting in murkier legal territory under the Computer Misuse Act 1990 and the DVLA’s own terms of service. The DVLA does pursue enforcement actions, but proving intent and scale in court is hard when the underlying data is publicly accessible.

    What fraudsters do with harvested vehicle data

    The obvious use case is cloning. If you know a legitimate vehicle’s make, model, colour, and approximate age from its registration, you can produce cloned plates that will pass a casual visual inspection and match any ANPR query on a road without DVLA enforcement cameras. Vehicle cloning has been a persistent problem in the UK; the DVLA and police forces acknowledge thousands of clone-related reports annually.

    Beyond cloning, harvested VRM data gets layered with other sources. Cross-reference a plate with council planning portals that list addresses, cross-reference that with Companies House records being abused for identity fraud, and you start building profiles. Fleet operators are particularly exposed because their vehicles tend to be clustered by postcode and registered to a single company address. A scraper that targets commercial plate formats can extract an entire fleet’s data and sell it to competitors or use it for targeted vishing attacks against fleet managers.

    Insurance fraud is another downstream abuse. Knowing that a specific vehicle lacks valid MOT or tax is useful if you’re planning to make a fraudulent claim against that vehicle’s owner, or if you want to verify that a vehicle you’re planning to acquire illegitimately hasn’t already been flagged. The same data that helps a legitimate buyer avoid purchasing an untaxed car helps a fraudster confirm a target is low-risk.

    Some of the more creative abuses feed into wider social engineering campaigns. The UK scambaiter exposing fraudsters community has documented cases where scraped vehicle data gets dropped into vishing scripts to make calls seem more credible. If a scammer can tell you the make, colour, and MOT status of the car on your driveway before you’ve said a word, the psychological effect on a target is significant.

    The authentication gap and why it persists

    The official DVLA Vehicle Enquiry API requires an API key tied to an approved account. That’s the right model. The problem is the public web service doesn’t enforce the same controls end-to-end. The DVLA’s own intermediary layer handles authentication on behalf of the browser user, which is standard practice, but it means that any rate limiting applied is based on IP or session heuristics rather than authenticated identity.

    Compare this with how HMRC’s systems handle equivalent public-facing data. HMRC’s CONNECT system is deliberately opaque about its own query infrastructure precisely because making bulk enumeration easy would undermine its fraud detection value. The DVLA doesn’t have the same luxury because vehicle tax and MOT status genuinely need to be publicly checkable, but the absence of any challenge mechanism on high-frequency queries from single sources is a design gap that has never been properly closed.

    Adding a CAPTCHA or proof-of-work challenge to the web form wouldn’t stop determined programmatic scrapers for long, but it would raise the cost. Implementing anomaly detection on query patterns (sequential VRM enumeration is obvious when you look at the logs) and feeding that into a threat intelligence feed is the more robust approach. The NCSC’s Early Warning service is built around exactly this kind of behavioural signal analysis, but that architecture isn’t currently connected to DVLA’s public query infrastructure in any visible way.

    What would actually fix this

    The simplest mitigation is aggressive IP-based rate limiting with exponential backoff on the public web service, combined with log analysis for sequential or near-sequential VRM patterns. Not groundbreaking, not expensive. The DVLA already has the telemetry to do this.

    Longer term, moving the public-facing VES to a model where users authenticate with GOV.UK One Login would allow per-user query limits and proper audit trails. GOV.UK One Login’s architecture is built to handle exactly this kind of authenticated public service interaction. Yes, adding login friction will reduce casual use. That’s the trade-off the DVLA needs to have an honest conversation about publicly.

    The DVLA does publish its API terms of service and runs takedowns against commercial entities it identifies scraping without authorisation. But reactive enforcement after the fact is a lot less useful than building the detection into the infrastructure from day one. The data is too rich, too accessible, and too useful to bad actors for the current approach to hold much longer.

  • How the FCA’s RegTech Data Pipelines Work: The Automated Surveillance Systems Watching UK Financial Markets for Manipulation

    How the FCA’s RegTech Data Pipelines Work: The Automated Surveillance Systems Watching UK Financial Markets for Manipulation

    The Financial Conduct Authority is not some bloke in a suit skimming spreadsheets. It is, at its core, a data operation. A surveillance machine that ingests billions of rows of trade data every day, runs it through pattern-matching engines, and flags anomalies for human review. The FCA market surveillance RegTech UK stack is one of the more quietly impressive pieces of financial infrastructure most people have never thought about. And because most people haven’t thought about it, some clever operators have found the seams.

    This is a technical breakdown. We’re going into the plumbing: how data flows in, what the detection logic looks like, and where the logic quietly falls apart.

    FCA market surveillance RegTech UK operations centre with multiple data screens showing live trading patterns at night

    Where the Data Actually Comes From

    Under the UK’s retained version of MiFID II (now domesticated into the UK Markets in Financial Instruments framework post-Brexit), firms are required to report executed trades to Approved Reporting Mechanisms (ARMs). Think of ARMs as glorified relay nodes: brokers and trading venues funnel their transaction reports through providers like Unavista (London Stock Exchange Group), Tradeweb, or DTCC Derivatives Repository. These ARMs then pipe standardised records straight into the FCA’s Transaction Reporting system.

    Each report is a structured data packet covering around 65 fields: financial instrument identifier (ISIN or AII), price, quantity, execution time (to microsecond precision), trader identifiers, counterparty LEI codes, and a bunch of venue and capacity flags. The FCA reportedly processes north of 10 million transaction reports on a busy day. That is not a small firehose.

    On the derivatives side, trade repositories (TRs) like DTCC and ICE Trade Vault handle EMIR reporting, pushing position-level data and lifecycle events into a separate regulatory channel. The FCA cross-references both streams. At least in theory.

    The Algorithmic Surveillance Layer

    Once the data lands, it doesn’t sit in a queue waiting for a compliance officer to manually check it. The FCA runs a suite of automated surveillance tools that operate across several abuse typologies defined under the UK Market Abuse Regulation (UK MAR). The main categories they’re scanning for are insider trading, market manipulation (including layering, spoofing, and ramping), and wash trading.

    The detection logic for each works differently.

    For insider trading, the system primarily looks at pre-announcement positioning. It maps trades executed in the window before a price-sensitive event (earnings, M&A announcements, regulatory decisions) against the identity of the counterparties. Unusually large directional trades by accounts with demonstrable proximity to material non-public information trigger a case. The challenge is that correlation is not causation, and the FCA’s false positive rate here is notoriously high, which means a lot of cases get opened and quietly shelved.

    For layering and spoofing, which is where things get genuinely technical, the system analyses order book events at millisecond resolution. Layering involves placing large visible orders on one side of the book to push price, then cancelling them once your actual order fills on the other side. The surveillance engine looks for high order-to-trade ratios, short order lifetimes, and directional asymmetry between placed and executed volume. This is the kind of detection logic that was pioneered by exchanges like NASDAQ and the London Stock Exchange’s own surveillance platforms before regulators built their own versions.

    Where the Detection Logic Has Gaps

    Here’s where it gets interesting. The FCA’s infrastructure, however impressive in scope, has structural weaknesses that aren’t exactly secret in quantitative finance circles.

    The first is latency in cross-venue data fusion. UK equity trades can execute across multiple venues simultaneously: the London Stock Exchange, CBOE Europe, Aquis Exchange, dark pools, and systematic internalisers. The FCA’s surveillance has to correlate activity across all of them to detect coordinated manipulation. Because ARM submission windows allow for T+1 reporting in some cases, a spoofing pattern that spans venues may not look suspicious in any single dataset but screams manipulation when you look at the whole picture. By the time the full picture is assembled, the pattern has already resolved and the money is moved.

    The second gap is derivatives-to-spot linkage. Sophisticated manipulation increasingly starts in less-liquid derivatives markets, where a small position can move a reference price that then triggers payoffs in a much larger physical or structured product. The EMIR reporting stream and the MiFIR transaction reporting stream are not natively joined in real time. Analysts at the FCA can request cross-referenced queries, but there’s no live, automated alert firing across that seam. That’s a known problem.

    Third is the identity obfuscation layer. LEI codes (Legal Entity Identifiers) are supposed to make counterparty identification trivial. In practice, complex fund structures involving multiple SPVs across Jersey, Cayman, and Luxembourg can make beneficial ownership genuinely ambiguous at the point of reporting. The FCA can issue formal information requests and use their powers under FSMA 2000 to compel disclosure, but that’s a reactive process, not a real-time detection capability.

    The FCA has acknowledged some of these limitations publicly. Their 2023 and 2024 market cleanliness statistics showed that UK equity markets have actually improved on some traditional insider trading metrics, but the regulator has also flagged concerns about shifting abuse patterns into derivatives and less-regulated instruments. You can read more about the FCA’s market cleanliness work directly on their market abuse regulatory hub.

    The RegTech Vendors Plugging the Gaps

    Because the FCA can’t build everything internally, a whole ecosystem of RegTech vendors has grown up around the problem. Firms like Behavox, NICE Actimize, and Nasdaq’s own Surveillance platform sell directly to trading firms and banks for their internal compliance functions. Some of these platforms now use machine learning models trained on historical enforcement actions to score new order patterns probabilistically.

    The irony is that firms subject to FCA oversight are running surveillance technology that, in some cases, is more sophisticated than what the regulator itself is running. A major bank’s internal spoofing detection can fire an alert within seconds of a suspicious pattern. The FCA’s equivalent system may not see the same data at the same fidelity until reports are submitted and ingested, which could be hours later on a high-volume day.

    What the Future of FCA Market Surveillance Looks Like

    The FCA has been making noises about its data strategy for a while now. Their Transforming Data Collection programme (TDC), running in collaboration with the Bank of England, is specifically aimed at modernising how regulators ingest, validate, and use financial data. The aspiration is closer to real-time regulatory reporting rather than the current batch submission model. If it lands properly, some of those cross-venue and derivatives linkage gaps could be genuinely closed.

    There’s also increasing interest in using graph-based analytics for network analysis: mapping the connections between traders, accounts, and counterparties across time to surface unusual clustering. It’s the same approach fraud teams at banks use for financial crime detection, applied to market structure data.

    Whether the FCA builds that capability internally or procures it from the RegTech market is an open question. Given the pace of hiring in the public sector versus the private sector for quant and data engineering talent, my money is on procurement. Either way, the surveillance net is getting tighter. Slowly. And the people who understand exactly how it works, and where it currently doesn’t, are watching very carefully.

    Frequently Asked Questions

    What is the FCA's market surveillance system and how does it work?

    The FCA runs automated surveillance systems that ingest trade data reported via Approved Reporting Mechanisms under MiFID II/MiFIR rules. The system applies algorithmic detection logic to flag suspicious patterns like spoofing, layering, and insider trading positioning, which are then reviewed by enforcement teams.

    What is RegTech and why does it matter for UK financial regulation?

    RegTech (Regulatory Technology) refers to software and data systems used to comply with and enforce financial regulations. In the UK, it includes the reporting infrastructure firms use to submit trades to the FCA and the surveillance platforms the regulator uses to detect market abuse at scale.

    How does the FCA detect spoofing and layering in UK markets?

    The FCA’s surveillance tools analyse order book data at millisecond resolution, looking for high order-to-trade ratios, extremely short order lifetimes, and patterns where large visible orders are placed and cancelled in coordination with actual executions on the opposite side. This is technically complex and generates significant false positives.

    What are the biggest gaps in the FCA's market abuse detection?

    The main weaknesses include latency in fusing data across multiple trading venues, the lack of real-time linkage between EMIR derivatives reporting and MiFIR equity transaction reports, and difficulty piercing complex fund structures to identify beneficial ownership at the point of surveillance.

  • How Rogue Android APKs Are Draining UK Banking Apps: Overlay Attacks, Accessibility Abuse, and Why Google Play Protect Keeps Missing Them

    How Rogue Android APKs Are Draining UK Banking Apps: Overlay Attacks, Accessibility Abuse, and Why Google Play Protect Keeps Missing Them

    There’s a particular breed of mobile malware circulating right now that is, honestly, quite elegant in the worst possible way. It doesn’t brute-force anything. It doesn’t need root access. It just waits, watches, and quietly empties your Barclays account while you think you’re logging in normally. Android banking malware in the UK has matured significantly heading into 2026, and the gap between what these samples can do and what most people’s defences actually catch is genuinely uncomfortable to look at.

    This isn’t scare journalism. This is a technical walkthrough of how these attacks are constructed, why they’re effective against specific UK banks, and where the detection pipelines are falling over.

    Hooded figure holding Android phone showing banking app in context of android banking malware uk 2026

    The Delivery Chain: How the APK Gets on Your Device

    Forget the Play Store for a second. The primary delivery vector for UK-targeted banking trojans right now is smishing: an SMS or WhatsApp message, often spoofed to appear from Royal Mail, HMRC, or a known bank, pointing to a domain that serves a malicious APK. The lure page is frequently a near-pixel-perfect clone of the legitimate app’s Play Store listing, complete with fake review counts and version numbers.

    The user is told to enable “Install from unknown sources” because the fake page explains the app is a “security update” or “fraud detection tool” that isn’t yet in the official store. It sounds absurd written out, but these pages are polished, the SMS sender IDs are spoofed convincingly, and the social engineering is tight. NCSC’s own guidance on malicious SMS campaigns documents exactly this pattern, and the volume of reports to Action Fraud from UK residents has been climbing steadily through 2025 and into this year.

    Once the APK is installed, it typically requests a minimal set of permissions on first launch: just enough to look plausible. The dangerous requests come later, incrementally, once trust is established.

    Overlay Attacks: The Fake Login You Can’t Tell Is Fake

    The overlay technique is the oldest trick in the Android malware playbook, and it still works because the fundamental Android permission model hasn’t closed the attack surface cleanly. Here’s what’s actually happening at the system level.

    The malware registers a foreground service and monitors the device’s running tasks, typically via ActivityManager.getRunningTasks() on older API levels, or more recently by abusing the Accessibility Service to observe window state change events. When it detects that the user has opened a target application, such as Barclays Mobile Banking or the Monzo app, it fires an overlay window using the TYPE_APPLICATION_OVERLAY window type (which replaced the deprecated TYPE_SYSTEM_ALERT after Android 8). This overlay sits on top of the real app. To the user, they’re looking at what appears to be a normal login screen. They’re actually typing credentials into a WebView or a custom layout controlled entirely by the malware.

    The collected credentials are exfiltrated immediately via HTTPS to a command-and-control server, often hosted on bulletproof infrastructure in jurisdictions that don’t respond quickly to UK law enforcement requests. Some samples I’ve reviewed use Telegram bot APIs as a lightweight C2 channel, which is clever because outbound Telegram traffic rarely triggers corporate or ISP-level filtering.

    Accessibility Service Hijacking: The Permission That Breaks Everything

    If overlay attacks are the front door, accessibility service abuse is the skeleton key. Once a malicious app has been granted Accessibility Service permissions, it has extraordinary visibility into the device.

    Specifically, an app with these permissions can read the content of any screen element using AccessibilityNodeInfo, simulate touch events and button presses, intercept and act on window content change events, and auto-fill or auto-dismiss UI elements without user interaction. For a banking trojan, this means it can observe the NatWest app rendering your account balance, read OTP codes as they appear on screen before you’ve had a chance to type them, and then dismiss notifications so you don’t notice the outgoing transfer that just happened.

    Android’s own defences here are genuinely weak. Google has tried restricting which apps can declare accessibility services in recent Play Store policies, but since these trojans are sideloaded rather than distributed via the Play Store, those restrictions are irrelevant. The DRAW_OVER_OTHER_APPS permission and Accessibility access together are sometimes called the “God mode” combination in mobile security circles, and it’s a fair description.

    Some current UK-targeting samples have started bundling a secondary technique: they request device admin privileges under the guise of an “enterprise security profile”, which then prevents the user from uninstalling the malware through normal means. You try to remove it and the uninstall button is greyed out.

    SMS Interception and Why UK Two-Factor Authentication Isn’t Saving You

    Here’s where UK banks specifically have a problem. Barclays, NatWest, and several smaller institutions still rely heavily on SMS OTP for transaction authorisation. The malware intercepts these codes using a BroadcastReceiver registered for the SMS_RECEIVED intent. On Android versions below 10, this worked almost unimpeded. On more recent builds, the malware increasingly uses the Accessibility Service to read the SMS notification as it appears in the notification shade, which sidesteps the direct SMS permission requirement entirely.

    The interception happens in milliseconds. The C2 server, watching the exfiltrated credentials arrive, uses the stolen OTP to authorise a Faster Payments transfer before it expires. By the time the legitimate account holder has noticed anything unusual, the money is already in a mule account and on its way out of the UK financial system. Monzo’s in-app notifications and real-time spend alerts are a partial mitigation because they surface the transaction immediately, but if the malware is also suppressing notifications, that safety net disappears.

    The NCSC’s guidance on phone-based attacks acknowledges SMS as a weaker second factor and recommends app-based authentication where available. The problem is that adoption of app-based TOTP or passkey-style authentication among mainstream UK retail banking users remains low, and the banks themselves have been slow to deprecate SMS entirely because it reduces friction for less technically literate customers.

    Why Google Play Protect Isn’t Catching This

    Play Protect scans apps on the device using Google’s on-device and cloud-based detection pipeline. It’s not useless. But it has a fundamental structural problem against this threat: the malicious APKs are delivered outside the Play Store ecosystem, and Play Protect’s behavioural detection has historically been weaker against apps that delay their malicious behaviour.

    Most of the UK-targeting samples use a dormancy period. The APK installs cleanly, behaves normally for a period of 24 to 72 hours, phones home to verify it’s running on a real device rather than an emulator or sandbox (standard anti-analysis checks: device fingerprint, SIM presence, battery state, accelerometer data), and only then activates the overlay and accessibility hooks. By the time the malicious behaviour starts, Play Protect has already assessed the app as benign.

    The anti-emulation checks are increasingly sophisticated. If the malware detects it’s running on a virtual device, it terminates quietly. This makes automated dynamic analysis far less effective without significant infrastructure investment to convincingly spoof real hardware environments.

    What Actually Helps

    On the device side: don’t sideload APKs, full stop. Enable Play Protect and keep it on. Revoke Accessibility Service permissions from any app that doesn’t have an obvious legitimate reason to need them. If your bank supports in-app biometric authentication backed by a hardware security module rather than SMS codes, enable it.

    On the bank’s side, what should be happening is stronger transaction-level behavioural analysis. Banks should be comparing device fingerprint, geolocation velocity, and session characteristics against established patterns. A login from a device that has never previously accessed the account, followed immediately by a Faster Payments transfer to a new payee, should trigger a hard block pending manual verification. Some UK challenger banks are further along with this than the legacy high-street institutions. The irony is that Monzo, frequently targeted precisely because of its younger demographic’s likelihood to sideload apps, arguably has better real-time fraud detection than most of the older banks.

    For anyone actually interested in the technical details of these samples, the ThreatFabric research blog and the Cleafy team publish excellent detailed analyses of active Android banking trojan families. The Anatsa and Copybara families have both been documented targeting UK financial institutions specifically in recent reporting periods, and the techniques I’ve described above are directly observable in their decompiled code.

    Frequently Asked Questions

    What is android banking malware and how does it target UK users in 2026?

    Android banking malware is malicious software that impersonates or monitors legitimate banking apps to steal credentials, OTP codes, and authorise fraudulent transactions. In the UK, current variants specifically target Barclays, NatWest, and Monzo using smishing campaigns that trick users into sideloading APKs outside the Google Play Store.

    How do overlay attacks on Android banking apps actually work?

    The malware monitors the device for when a banking app is opened, then draws a fake login screen on top of it using Android’s TYPE_APPLICATION_OVERLAY window type. The user types their credentials into the fake screen without realising, and those details are immediately sent to an attacker-controlled server.

    Can Google Play Protect detect and remove banking trojans?

    Play Protect has limited effectiveness against these threats because the APKs are sideloaded rather than installed from the Play Store, and modern samples deliberately delay malicious behaviour to pass initial scans. Its on-device behavioural detection can flag some activity but it is not reliable against evasion-aware samples.

    Why is SMS two-factor authentication not enough to stop these attacks?

    Malware with SMS interception capability or Accessibility Service access can read OTP codes the moment they arrive, either directly from the SMS broadcast or from the notification shade. The stolen code is forwarded to the attacker’s infrastructure within milliseconds, before the legitimate user has a chance to act.

    How do I protect my Android device from banking malware in the UK?

    Never install APKs from outside the Google Play Store, and be sceptical of any SMS or WhatsApp message prompting you to download a security update or banking tool. Check which apps have Accessibility Service permissions in your device settings and revoke access from anything that doesn’t genuinely require it. Use app-based authentication rather than SMS codes wherever your bank offers it.

  • NCSC Early Warning: How the UK’s Threat Intel Platform Actually Works (and Where It Goes Blind)

    NCSC Early Warning: How the UK’s Threat Intel Platform Actually Works (and Where It Goes Blind)

    The NCSC Early Warning service UK architecture is one of those things that gets mentioned in government briefings and CISO presentations but rarely gets pulled apart at the technical level. Most coverage treats it like a magic box: threats go in, alerts come out, everyone’s safer. That’s not how it works. There’s a specific data pipeline underneath it, with real limitations baked in by design, and understanding those limitations matters a lot more than the marketing copy suggests.

    Let’s get into the actual mechanics.

    Cybersecurity analyst monitoring NCSC early warning service UK architecture on dark operations centre screens

    What the NCSC Early Warning Service Actually Is

    Early Warning is a free service from the National Cyber Security Centre that notifies registered UK organisations when their IP ranges or domains appear in threat intelligence data. It’s not an active scanner. It’s not a firewall. It’s a passive aggregation and notification layer that sits on top of third-party and proprietary feeds, then matches indicators against an organisation’s declared assets.

    Eligibility is open to any UK organisation, from a sole-trader running a couple of servers to a FTSE 100 company with a sprawling ASN. Sign-up involves verifying ownership of the IP space or domain in question, which is a lightweight but necessary check to prevent people from registering assets they don’t own and harvesting intelligence on competitors.

    How Threat Feed Ingestion Actually Works

    The NCSC draws on a mixture of feeds. Some are proprietary, collected through the Centre’s own sensors and incident data. Others come from trusted commercial partners and CERT sharing arrangements across the EU and Five Eyes network. On top of that, there are open-source threat intelligence (OSINT) feeds, think Shadowserver, abuse.ch, and similar operations that track botnet C2 infrastructure, compromised hosts, and malware distribution networks globally.

    Shadowserver in particular deserves a mention here. It scans a significant portion of the routable IPv4 space daily and shares data with national CERTs and bodies like the NCSC. The volume of data coming in from these combined sources is enormous. The interesting engineering problem isn’t collecting it; it’s deduplication, confidence scoring, and timeliness.

    Each indicator (an IP, a domain, a hash, a URL) carries metadata: when it was first seen, when it was last confirmed active, what threat category it maps to (C2, scanning, phishing kit, credential stuffing, etc.), and a confidence rating. Low-confidence indicators from a single source don’t trigger notifications. The system applies a kind of rough consensus model, where an IP flagged independently by multiple feeds at similar timestamps earns a higher confidence score and is more likely to surface as an alert.

    Mapping Indicators to UK IP Space

    This is where the NCSC Early Warning service UK architecture gets genuinely interesting. The platform maintains a continuously updated map of which IP ranges belong to which registered organisations. BGP routing tables, RIPE NCC allocation data, and the self-declared assets from enrolled organisations all feed into this mapping layer.

    When an indicator matches a registered IP or domain, an alert fires. The format is deliberately minimal: what was seen, when, and what category of threat. There’s no full packet capture, no context about how deep the compromise runs, and no remediation guidance beyond generic signposting. The NCSC is explicit about this. Early Warning is a notification service, not an incident response platform.

    Alerts are delivered via a web dashboard and optionally via email or the NCSC’s own API, which allows organisations with a SOC to pipe alerts directly into their SIEM. That API integration is one of the more useful features for anyone running a proper security operation rather than checking a dashboard manually every Tuesday morning.

    Where the Visibility Completely Falls Apart

    Here’s the honest part. The NCSC’s own documentation is reasonably candid about limitations, but it doesn’t spell them out in technical terms for people who actually need to understand the gaps.

    Cloud and shared infrastructure. If your organisation runs workloads on AWS, Azure, or Google Cloud, the IP addresses belong to those providers, not to you. Early Warning maps to announced IP space and declared assets. An attacker hitting your EC2 instance looks, at the network layer, like someone hitting Amazon’s IP range. Unless you’ve explicitly registered those specific IPs (which rotate in some architectures), the correlation won’t happen. This is a structural gap affecting a huge proportion of UK companies in 2026.

    Encrypted C2 and domain-fronting. Feed-based detection relies on indicators reaching the public threat intelligence ecosystem. Modern nation-state and organised criminal tooling increasingly uses legitimate infrastructure for command-and-control. Traffic that blends into normal HTTPS across CDN providers leaves almost no fingerprint that propagates to shared feeds. Early Warning sees nothing here.

    Zero-day and first-party compromise. The feed model is inherently retrospective. An indicator has to be seen, attributed, and shared before it can trigger an alert. Novel malware families or freshly registered C2 domains have a lag period of anywhere from hours to weeks before they appear in threat intelligence. During that window, Early Warning is silent.

    Insider threats and credential abuse. Legitimate credentials used from legitimate IP ranges produce no anomalous network indicators. Early Warning has no behavioural analytics component. It won’t notice that someone’s Office 365 account is being accessed from an unusual geography at 03:00 GMT, because that’s not what it’s built to detect.

    IPv6 coverage. Shadowserver and similar scanners have significantly less IPv6 coverage than IPv4. If your organisation has moved significant workloads onto IPv6 addressing, the threat intelligence coverage you’re receiving is materially thinner. This is a problem that the broader threat intelligence community is aware of but hasn’t solved at scale.

    Who Actually Benefits from This Service

    Early Warning delivers genuine value in specific contexts. A mid-sized UK manufacturer with a flat, on-premises network and a modest IP range will see real utility from knowing when those addresses appear in botnet data or when a mail server starts appearing on spam threat feeds. For that kind of organisation, it’s a meaningful signal that probably wouldn’t surface otherwise.

    For a mature enterprise with a SOC, a commercial threat intelligence subscription, and a SIEM already ingesting Shadowserver and similar feeds directly, Early Warning is largely redundant. You’re already seeing those indicators through other channels, often faster. The value proposition narrows to the NCSC’s proprietary feeds, which contain intelligence derived from UK government sensor networks and incident response engagements that aren’t replicated elsewhere.

    Universities and NHS trusts sit in an interesting middle ground. They often have large, registered IP ranges with relatively limited security tooling. For those organisations, Early Warning can catch things that would otherwise go unnoticed for months.

    Using the API Properly

    If you’re registered and not using the API, you’re leaving the most useful part on the table. The REST API lets you pull structured alert data into whatever stack you’re running. A basic Python script hitting the endpoint on a schedule and feeding results into an Elasticsearch index takes an afternoon to build. From there you can correlate Early Warning alerts against your own firewall logs and actually determine whether a flagged IP successfully reached your infrastructure or got dropped at the perimeter. That correlation step is where the real analysis happens; the raw alert alone tells you very little about severity.

    The NCSC also publishes STIX/TAXII feeds for organisations that prefer a standardised threat intelligence format, which integrates cleanly with platforms like OpenCTI or MISP if you’re running a proper threat intelligence operation internally.

    The NCSC early warning service UK architecture is a solid piece of public infrastructure for what it’s designed to do. Treat it as one layer in a defence stack, not the stack itself, and be honest about the categories of threat it simply cannot see. That’s not a criticism of the NCSC; it’s the nature of passive, feed-based detection at national scale. The gaps are structural, and knowing them is half the battle.

    Frequently Asked Questions

    Is the NCSC Early Warning service free to use?

    Yes, it’s entirely free for any registered UK organisation. You sign up via the NCSC website, verify ownership of your IP ranges or domains, and start receiving alerts at no cost. There’s no paid tier.

    How quickly does the NCSC Early Warning service send alerts after a threat is detected?

    It depends on the underlying feed. Some feeds share indicators in near real-time; others have latency of several hours or more before indicators propagate. Freshly observed threats can have a lag of hours to days before appearing in the intelligence ecosystem the NCSC draws on.

    Can the NCSC Early Warning service detect ransomware attacks?

    Partially. It can detect activity associated with known ransomware precursors, such as C2 infrastructure from established ransomware groups that’s already been documented in threat feeds. It cannot detect novel ransomware delivery or purely internal lateral movement that doesn’t touch flagged external infrastructure.

  • Inside the EU Cyber Resilience Act: What UK Software and Hardware Vendors Actually Have to Implement by 2027

    Inside the EU Cyber Resilience Act: What UK Software and Hardware Vendors Actually Have to Implement by 2027

    The EU Cyber Resilience Act (CRA) received its final approval in late 2024 and its technical requirements are now ticking toward full enforcement. UK vendors who sell digital products into Europe have a hard deadline approaching, and the requirements are not light. We are talking mandatory vulnerability disclosure windows measured in hours, software bills of materials that have to be machine-readable, and default security configurations baked into hardware before a single unit ships. UK product teams are quietly, sometimes frantically, working out what this means for them. Because Brexit did not make the problem go away. If anything, it made it more complicated.

    Hacker reviewing Cyber Resilience Act UK obligations 2027 on multiple monitors in a dark server room
    Hacker reviewing Cyber Resilience Act UK obligations 2027 on multiple monitors in a dark server room

    Why the CRA Still Applies to UK Vendors Post-Brexit

    Here is the thing people get wrong. They assume that because the UK is no longer bound by EU law, European regulations are someone else’s problem. That logic falls apart the moment your product is sold to a customer in Frankfurt or Amsterdam. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK companies exporting to Europe are fully in scope. The EU does not care that your company is registered at Companies House and your servers are in Slough.

    The UK government, for its part, has been developing its own Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024. PSTI covers consumer IoT devices and has some overlapping concerns with the CRA, but the two are not equivalent. PSTI is narrower. The CRA is considerably more demanding and covers a far wider category of software and hardware. UK vendors effectively have to satisfy two separate regulatory regimes simultaneously if they trade in both markets, and the stricter of the two sets the practical floor.

    What the Cyber Resilience Act UK Obligations 2027 Actually Require

    Vulnerability Disclosure: The 24-Hour Rule

    The CRA mandates that manufacturers notify ENISA (the EU Agency for Cybersecurity) of actively exploited vulnerabilities within 24 hours of becoming aware of them. A full vulnerability report follows within 72 hours. This is brutal compared to what most UK product teams are used to. Many organisations currently operate on informal disclosure timelines that stretch across weeks. Under the CRA, 24 hours is the window from awareness to notification, not from patch development to public announcement. UK vendors need a documented incident response process that can actually hit that target, which means tooling, clear ownership, and a direct pipeline to ENISA’s reporting mechanisms.

    The UK’s National Cyber Security Centre (NCSC) has its own coordinated vulnerability disclosure guidelines, which you can review at ncsc.gov.uk. The NCSC framework is broadly sensible but does not impose the same hard legal timelines the CRA does. UK teams targeting EU markets need to treat the CRA timeline as the operative one.

    Developer generating an SBOM output as part of Cyber Resilience Act UK obligations 2027 compliance
    Developer generating an SBOM output as part of Cyber Resilience Act UK obligations 2027 compliance

    Software Bill of Materials: The SBOM Mandate

    An SBOM is essentially an ingredient list for your software. Every component, library, dependency, and third-party module, catalogued in a machine-readable format. The CRA requires manufacturers to produce and maintain SBOMs for products with digital elements. The practical pain here is significant. Large codebases with years of accumulated dependencies can have hundreds of components, some of which are abandoned open-source projects that nobody has touched since 2019. Generating an SBOM is one thing. Keeping it accurate as dependencies update, forks happen, and supply chains shift is an ongoing operational commitment.

    The standard formats getting traction are CycloneDX and SPDX. Tooling exists to automate SBOM generation from source trees and container images, but the output is only as good as the engineering hygiene that produced the codebase. Teams relying on undocumented vendored code or tangled monorepos are in for a rough time. The SBOM also feeds directly into vulnerability management: once you have a machine-readable component list, you can cross-reference it against CVE databases and catch exposure before it becomes a breach notification event.

    Secure-by-Default Configuration Requirements

    The CRA requires products to ship in a secure-by-default state. No more factory passwords shared across every unit. No more open ports that the user is expected to close themselves. No more optional security features that are off unless you know where to look in a settings menu buried three layers deep. The default state of the product must be the secure state. This has hardware implications and software implications in equal measure.

    For web-facing software and hosted products, this translates into enforced HTTPS, no default admin credentials, automatic security updates on by default, and clear discoverability of security settings. The days of shipping a product and leaving hardening as an exercise for the customer are over, at least if you want to sell into Europe legally.

    Which Product Categories Are in Scope

    The CRA splits products into default, important, and critical categories, with increasing requirements at each tier. Most commercial software products sold to businesses and consumers fall into the default category, which still carries substantial obligations. Important products, covering things like password managers, VPNs, routers, and industrial control interfaces, face third-party conformity assessments before they can carry the CE mark the CRA requires. Critical products, including hardware security modules and smart meter gateways, face the most rigorous scrutiny.

    UK vendors supplying B2B software platforms to European enterprise customers need to honestly assess which tier their product sits in. Getting that classification wrong is not a neutral error. Treating an important product as a default product and skipping third-party assessment is exactly the kind of shortcut that generates enforcement action.

    The Practical Scramble Happening Inside UK Product Teams Right Now

    Talk to anyone deep inside a UK software vendor’s security or engineering team and you will hear the same themes. SBOM tooling is being evaluated and bolted onto CI/CD pipelines. Legal teams are trying to map the CRA’s requirements against existing contract frameworks. Product managers are realising that their roadmap for the next 18 months has to absorb compliance work that was not originally budgeted. The Cyber Resilience Act UK obligations 2027 deadline sounds distant until you account for the lead time required to retrofit secure-by-default behaviour into legacy products, build SBOM generation into release pipelines, and train incident response teams on the 24-hour notification clock.

    Web-facing businesses and digital agencies are not immune to this either. Organisations building software products or hosting environments for clients face questions about where their liability sits when a component they ship or maintain carries an unpatched CVE. Businesses like dijitul, a Mansfield, Nottinghamshire-based digital agency specialising in web design, hosting, and software delivery, are already fielding questions from clients about how CRA-adjacent obligations affect the platforms and web properties being managed on their behalf. For an agency operating across marketing, business efficiency tools, and bespoke web builds, the practical question is which of the products and services they deliver would qualify as products with digital elements under CRA definitions. The answer, in many cases, is more of them than you might expect. dijitul.uk is a useful reference point for understanding how smaller digital businesses are thinking through their own product and service taxonomy in light of these requirements.

    The companies that will sail through the 2027 deadline are the ones treating this as an engineering problem now, not a compliance checkbox exercise in 2026. That means adopting dependency scanning tools like Dependabot or Grype as permanent fixtures, not one-off audits. It means building vulnerability triage into sprint cycles. It means having a named person who can make the call at 2am when a critical CVE drops and the 24-hour ENISA window starts ticking.

    How to Start Getting Ready

    The sensible starting point is a product inventory: list everything your organisation ships or maintains that has digital elements and could plausibly reach EU markets. Then classify each item against the CRA’s three tiers. From there, gap analysis against the core technical requirements gives you a prioritised work list. Vulnerability disclosure process first, because the 24-hour window is the most operationally disruptive requirement and the hardest to bolt on retroactively.

    For smaller UK product teams, the SBOM mandate is probably the second most urgent thing to tackle. Integrating CycloneDX generation into your build pipeline is a one-time engineering investment that pays ongoing dividends for both CRA compliance and your own internal vulnerability management posture. It is also the kind of thing that digital agencies running software products for clients, focused on marketing and business efficiency as much as raw web design, need to factor into their service documentation and client-facing agreements.

    The Cyber Resilience Act UK obligations 2027 are not going to be watered down. The EU has spent years building the political and regulatory momentum behind this legislation and enforcement is expected to be real. UK vendors who sell into Europe cannot afford to wait and see. The scramble is already happening. The question is whether your team is in it.

    Frequently Asked Questions

    Does the EU Cyber Resilience Act apply to UK companies after Brexit?

    Yes. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK vendors selling software or hardware into EU member states are fully in scope and must meet the same requirements as EU-based manufacturers.

    What is the vulnerability disclosure timeline under the Cyber Resilience Act?

    Manufacturers must notify ENISA of an actively exploited vulnerability within 24 hours of becoming aware of it, followed by a full vulnerability report within 72 hours. This is significantly stricter than most informal disclosure practices currently used by UK product teams.

    What is an SBOM and why does the CRA require one?

    A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, library, and dependency in a software product. The CRA mandates SBOM production and maintenance so that vulnerabilities in third-party components can be rapidly identified and disclosed across the supply chain.

    What does secure-by-default mean under the Cyber Resilience Act?

    Products must ship in a hardened state without shared default passwords, unnecessary open ports, or security features that are disabled out of the box. The burden of configuration is placed on the manufacturer, not the end user, before the product reaches market.

    What is the difference between the UK PSTI Act and the EU Cyber Resilience Act?

    The UK’s Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024, covers consumer IoT devices and has narrower scope than the CRA. UK vendors selling into EU markets must satisfy both regimes, and the CRA’s requirements are considerably more demanding in most areas.

  • How UK Mobile Networks Handle Emergency Location Data: The SS7 Infrastructure Behind 999 Call Tracing

    How UK Mobile Networks Handle Emergency Location Data: The SS7 Infrastructure Behind 999 Call Tracing

    When you dial 999 from a mobile, there is a quiet war happening in the background. Your handset, the mast it is connected to, and a chain of ageing signalling protocols all scramble to answer one critical question: where exactly are you? The answer involves a stack of technology that ranges from genuinely modern to embarrassingly legacy, and the gaps between those layers are where both life-saving accuracy and some genuinely nasty attack vectors live. SS7 vulnerabilities in the UK mobile network are not theoretical. They are real, documented, and still largely unresolved, even as regulators push for better standards on 999 call location.

    Anonymous hacker in server room examining SS7 vulnerabilities in UK mobile network infrastructure
    Anonymous hacker in server room examining SS7 vulnerabilities in UK mobile network infrastructure

    What is SS7 and Why Does a 999 Call Touch It?

    Signalling System No. 7, almost always shortened to SS7, is the set of telephony protocols that mobile and fixed-line networks use to exchange control information. Think of it as the nervous system underneath a call, not the voice data itself but the signalling layer that handles routing, authentication, billing handshakes, and crucially, location data. It was designed in 1975 and standardised broadly through the 1980s. Its architecture assumed that only trusted carriers would ever connect to it. Spoiler: that assumption has aged terribly.

    When you make a 999 call in the UK, the network needs to route that call to the correct emergency call centre, which in practice means a BT-operated platform called the Emergency Call Handling Agent (ECHA). The ECHA then passes location information to the relevant emergency service control room. Getting accurate coordinates into that pipeline fast enough to matter requires pulling location data from multiple sources, and SS7 is one of the pipes that data flows through.

    The Three Layers of Location Data in a UK 999 Call

    Cell-ID: The Old Faithful That Can Get You Killed

    Cell-ID is the baseline. Every mast in the UK has a unique Cell Global Identity (CGI). When your phone registers with a mast, the network knows which cell you are in. In dense urban areas like central London or Manchester city centre, a cell might cover a few hundred metres. Out in rural Yorkshire, a single cell can stretch for several kilometres. That variance matters enormously when someone is unconscious in a field and the ambulance is being dispatched based on a 2km radius guess.

    Cell-ID data travels over SS7. The Home Location Register (HLR) and Visitor Location Register (VLR), classic SS7 database nodes, hold records of which cell a subscriber is currently in. A legitimate query to an HLR using an SS7 MAP (Mobile Application Part) message can return this Cell-ID. That same query can be issued by an attacker who has gained access to the SS7 network, which is exactly the problem.

    Advanced Mobile Location: The Standard That Actually Works

    Advanced Mobile Location, or AML, is the thing that genuinely changed the game. When a 999 call is initiated on a compatible handset, the phone automatically launches a brief background data session and sends a HTTPS request containing its best available position fix, which could be GPS, Wi-Fi positioning, or cell triangulation, directly to a secure national server. That data is then matched to the call and passed to the ECHA. No SS7 involvement in the location push itself. Clean, fast, and dramatically more accurate.

    Ofcom mandated AML support for UK mobile operators, and it has been rolling out since 2018. Research from the Emergency Location Task Force showed AML-capable devices achieving median location accuracies under 10 metres in tests, compared to hundreds of metres for Cell-ID alone. Android implemented AML natively; Apple’s equivalent, called Hybridised Emergency Location (HELO), integrates similarly. But here is the catch: AML only fires if the device supports it and has a data connection. No signal, no data, no AML. You fall back to Cell-ID. You fall back to SS7.

    Network-Derived Location via SS7 Queries

    When AML is not available, networks can attempt network-derived location using SS7-based procedures, pulling location from the network side rather than the handset. This involves MAP queries against the serving node, potentially triggering silent location requests. It is slower, less accurate, and it exposes exactly the same interface that attackers have been abusing for over a decade.

    Close-up of mobile signalling hardware representing SS7 vulnerabilities in UK mobile network 999 systems
    Close-up of mobile signalling hardware representing SS7 vulnerabilities in UK mobile network 999 systems

    The SS7 Attack Surface: What Legitimate Looks Like vs What an Attack Looks Like

    A legitimate location lookup over SS7 for emergency purposes looks like this: a trusted operator node sends a MAP-ATI (Any Time Interrogation) or MAP-PSL (Provide Subscriber Location) message to the target subscriber’s serving network. The serving network returns location data. The whole exchange happens between carrier-grade nodes with established inter-operator agreements.

    An attack looks almost identical. That is the problem. SS7 has no native cryptographic authentication between nodes. If an attacker has obtained access to an SS7 gateway, through a rogue operator connection (there are hundreds of legitimate interconnects globally), a compromised roaming hub, or a nation-state level intrusion, they can send the exact same MAP messages. The receiving network cannot reliably distinguish a query from BT’s legitimate infrastructure and a query from a compromised node in, say, a lightly regulated jurisdiction.

    Known attack types that are directly relevant here include:

    • MAP-ATI abuse: Silent location queries that return Cell-ID without the subscriber ever knowing. Used extensively in targeted surveillance operations documented by researchers at Positive Technologies and SRLabs.
    • IMSI harvesting via Paging: Forcing a phone to reveal its IMSI by sending forged paging messages, then correlating that IMSI with billing data.
    • SS7 intercept: Redirecting SMS messages by updating location registers, effectively breaking SMS-based two-factor authentication. UK banks and HMRC both still use SMS OTP for some authentication flows.
    • Call forwarding manipulation: Registering a supplementary service via SS7 to silently forward calls, including potentially 999 calls in extreme edge cases.

    The GSMA has published security guidelines (FS.11) specifically addressing SS7 vulnerabilities. UK mobile operators are expected to implement SS7 firewalls and anomaly detection. EE, Vodafone, O2, and Three have all made public commitments to SS7 hardening. But independent security researchers have consistently found that filtering is incomplete and that certain query types still pass through commercial networks globally.

    What Ofcom Has (and Has Not) Done About This

    Ofcom has pushed hard on the AML standard, which is the right call. Reducing reliance on SS7 for 999 location is genuinely the correct long-term direction. The General Conditions of Entitlement require UK operators to transmit caller location to the emergency services, and AML compliance is baked into that framework now.

    Where it gets murkier is the broader SS7 security mandate. Ofcom’s general network security obligations under the Communications Act 2003 and the Network and Information Systems (NIS) Regulations 2018 apply, but there is no specific published SS7 security audit regime with public reporting. Compare that to the approach taken by the US FCC, which has at least publicly demanded SS7 remediation reports from carriers, and the UK’s posture looks somewhat quieter than the scale of the problem warrants.

    The Gaps That Still Exist in 2026

    SS7 is not going away fast. VoLTE (Voice over LTE) and 5G use different signalling stacks, specifically Diameter for 4G and HTTP/2-based service-based architecture for 5G core. Both are improvements. Both also have their own vulnerability classes. But the global SS7 network still exists as an interconnect layer, particularly for roaming, and that interconnect layer is accessible. The migration to newer stacks is a decade-long project, not a flip of a switch.

    For 999 specifically, the risk is not that an attacker hijacks your emergency call in real time. That is technically complex and a weird threat model. The more realistic concern is the broader SS7 attack surface being used for surveillance, two-factor authentication bypass, and location tracking of individuals, all of which undermine the integrity of UK mobile communications more generally. Emergency location accuracy has genuinely improved with AML. But the underlying SS7 vulnerabilities in the UK mobile network remain a live issue for anyone who cares about mobile security beyond just calling 999.

    The honest summary: AML is good and getting better. Cell-ID fallback is a known weak point. SS7 is a creaking legacy protocol with documented, exploitable vulnerabilities that no single operator can fix unilaterally because the problem is global. Ofcom has done the right things on the emergency location side. The broader SS7 remediation piece remains a work in progress, and the security community knows it.

    Frequently Asked Questions

    What are SS7 vulnerabilities and do they affect UK mobile networks?

    SS7 vulnerabilities are security flaws in the Signalling System No. 7 protocol, a legacy telephony signalling stack used by mobile and fixed-line networks globally. Yes, they absolutely affect UK mobile networks because UK operators interconnect with the global SS7 network for roaming and inter-carrier signalling, creating exposure to attacks that can originate from compromised nodes anywhere in the world.

    How does Advanced Mobile Location (AML) improve 999 call accuracy?

    When you dial 999 on a compatible smartphone, the handset automatically sends a background HTTPS data packet containing its best GPS or Wi-Fi position fix directly to a secure national server, which then passes the data to the emergency call centre. This bypasses the less accurate Cell-ID method and typically achieves location accuracy within 10 metres in good conditions, compared to potentially hundreds of metres with network-derived Cell-ID alone.

    Can someone use SS7 to track a person's location in the UK without their knowledge?

    In theory, yes, and it has been demonstrated repeatedly by security researchers. An attacker with access to an SS7 gateway can send MAP-ATI (Any Time Interrogation) messages to a UK network to retrieve the Cell-ID of a target subscriber’s current location without any notification to the subscriber. UK operators are required to implement SS7 firewalls, but filtering is not universally complete across all query types and interconnect routes.

    Does 5G fix the SS7 security problem?

    5G’s core network uses a completely different signalling architecture based on HTTP/2 and a service-based model, which eliminates native SS7 exposure in the 5G core. However, 5G networks still maintain SS7 interconnects for backwards compatibility with older networks and global roaming, meaning the SS7 attack surface does not disappear immediately. Full migration away from SS7 will take many years.

    What does Ofcom require UK operators to do about emergency call location?

    Under the General Conditions of Entitlement, UK mobile operators are required to transmit caller location information to the emergency services for 999 calls. Ofcom has mandated support for Advanced Mobile Location (AML) as part of this requirement. Broader SS7 security is covered under the Communications Act 2003 and NIS Regulations 2018, though there is no specific published public audit regime for SS7 security compliance.

  • How HMRC’s CONNECT System Profiles Every Taxpayer: The Data Engine Hunting UK Tax Fraud

    How HMRC’s CONNECT System Profiles Every Taxpayer: The Data Engine Hunting UK Tax Fraud

    HMRC’s CONNECT system is one of the most sophisticated government analytics platforms in Europe. It quietly ingests, cross-references, and scores billions of data points about UK taxpayers, and most people have absolutely no idea it exists. Since its rollout in 2010, it has generated billions of pounds in recovered tax revenue. The fact that a government department built something this technically ambitious, and keeps it this quiet, is worth pulling apart properly.

    This isn’t a scaremongering piece. It’s a technical breakdown of what CONNECT actually does, how the data architecture probably works, what feeds it pulls from, and what the implications are if you care about data privacy in the UK.

    Server room representing HMRC CONNECT system data profiling UK taxpayer records
    Server room representing HMRC CONNECT system data profiling UK taxpayer records

    What Is HMRC CONNECT and How Does It Actually Work?

    HMRC CONNECT system data profiling UK taxpayers operates by aggregating data from dozens of sources, both public and private, and running machine learning models across them to spot discrepancies. At its core, the system is a risk-scoring engine. Every taxpayer gets a risk score. If your score crosses certain thresholds, a human compliance officer reviews your case. If the discrepancy looks large enough, an investigation opens.

    The architecture is built around a central data lake that ingests structured and semi-structured data from third-party feeds, compares declared income against observable lifestyle indicators, and runs clustering algorithms to identify anomalous patterns. Think of it less as a database and more as a continuous batch-processing pipeline with a scoring layer on top. HMRC has confirmed it uses technology from CODA, a data analytics platform originally developed by the now-defunct software firm, and that the system processes in excess of one billion pieces of data annually.

    Where Does the Data Come From? The Third-Party Feed Architecture

    This is where it gets genuinely interesting from a data engineering perspective. CONNECT doesn’t just look at your tax return. It pulls from a wide array of sources and triangulates them. Known data feeds include:

    • HM Land Registry: property ownership, purchase prices, transfer dates. If you bought a house for £650,000 on a declared income of £28,000 a year, the model notices.
    • DVLA: registered vehicle ownership. A fleet of expensive cars against modest declared earnings is a classic anomaly flag.
    • DWP: benefit claims and employment status. Cross-referencing active benefit claims with employment income is a straightforward inconsistency check.
    • Electoral roll: address history, household composition.
    • Companies House: directorships, shareholdings, filed accounts. If you’re a director of a profitable company, CONNECT knows.
    • Banks and financial institutions: under the Common Reporting Standard (CRS) and previous EU directives, financial institutions share account data with HMRC. Interest payments, investment income, offshore accounts, all flowing in.
    • Letting platforms and estate agents: rental income is a known CONNECT target. If you list a property on a major platform and don’t declare the income, the system can flag it.
    • Social media and online presence: this is the bit people really don’t like. CONNECT reportedly monitors publicly accessible social media data to look for lifestyle indicators inconsistent with declared income. Publicly posted images of expensive holidays, new vehicles, or business activity that doesn’t show up on a tax return are all fair game.
    Data analytics dashboard illustrating HMRC CONNECT system data profiling methodology
    Data analytics dashboard illustrating HMRC CONNECT system data profiling methodology

    Social Media as a Data Source: What HMRC Can Actually See

    The social media component of the HMRC CONNECT system data profiling UK operation is worth breaking down carefully, because this is where a lot of misconceptions live. HMRC cannot access private messages or locked accounts without a court order. What they can access, and do, is everything public. Public posts, public follower counts, public business promotions.

    This matters particularly for self-employed people who run public-facing social media profiles to advertise their business. A sole trader with a polished Instagram account showcasing high-end clients but declaring minimal earnings is exactly the kind of anomaly CONNECT is tuned to spot. The same logic applies to influencers and content creators, a growing slice of the UK workforce who often operate in murky territory between hobby and taxable trade. Anyone who uses social media actively as a business tool, posting to a quick landing page, running a link manager to direct followers to products or services, or using something like LinkVine (a UK-based link-in-bio tool at linkvine.uk that helps influencers and small businesses manage their links, build a quick landing page, and organise their social media presence in one place), is, in practice, demonstrating commercial activity to any system that monitors public-facing content. That’s not a flaw in the platform; it’s just how public data works.

    HMRC’s legal authority here is solid. Under Schedule 36 of the Finance Act 2008, HMRC has broad powers to request information from third parties. The ICO has repeatedly confirmed that public social media data can be processed for fraud prevention without breaching UK GDPR, provided it is proportionate. For a large-scale tax fraud detection system, proportionality is rarely challenged successfully.

    The Risk Scoring Model: What Triggers a Flag?

    CONNECT doesn’t trigger investigations randomly. It works on probabilistic scoring. Common triggers, based on publicly available HMRC technical documentation and academic analysis of the system, include:

    • Declared income significantly below local median for your occupation and postcode
    • Large unexplained deposits or property purchases relative to declared earnings
    • VAT return patterns inconsistent with sector benchmarks
    • Offshore account activity not reflected in declared income
    • Director loans that don’t appear to be repaid within the required timeframe
    • Mismatch between self-assessment submissions and RTI (Real Time Information) data from employers
    • Activity on letting or freelance platforms not reconciled with declared income

    The system uses what’s essentially a graph database model, mapping relationships between entities. You, your spouse, your limited company, your business partner, your property, your vehicles. Anomalies in any node of the graph can propagate suspicion across the connected entities. It’s clever architecture. If one director in a network of companies has a compliance issue, all connected entities get elevated scrutiny scores.

    What About Privacy Rights Under UK GDPR?

    The HMRC CONNECT system data profiling UK operation sits in a legally interesting space. HMRC is technically a data controller under UK GDPR, meaning you have a right to submit a Subject Access Request (SAR) and ask what data they hold on you. In practice, HMRC applies substantial public interest exemptions to limit what they disclose, particularly if disclosure would prejudice an ongoing investigation.

    The ICO’s guidance on data protection for public authorities sets out these exemptions clearly. HMRC can withhold information that would tip off a subject to an investigation, delay disclosure where national security or law enforcement interests are at stake, and refuse to confirm or deny the existence of certain processing activities. From a civil liberties standpoint, this creates a system where mass profiling happens with limited transparency or redress.

    Does CONNECT Catch the Big Players or Just the Self-Employed?

    Both, but the numbers skew interestingly. HMRC’s own figures suggest that the tax gap, the difference between owed and collected tax, sits at roughly £39.8 billion for the 2022/23 tax year (per official ONS-referenced HMRC data). Small business and self-employment non-compliance accounts for a significant chunk of that. CONNECT is particularly effective against this segment because the data signals are strong and consistent. Large corporate tax avoidance is harder to model, the structures are more complex, often technically legal, and the data is more opaque.

    That said, CONNECT has been credited with investigating high-net-worth individuals and property portfolios that would previously have required extensive manual investigation. The Land Registry and offshore financial feeds are particularly powerful for this segment.

    What Self-Employed and Online Businesses Should Actually Understand

    If you run any kind of online business, the practical takeaway is straightforward: your public-facing presence is data. Every tool you use to manage your links, build a social media presence, or run a quick landing page is contributing to a visible footprint. Creators who rely on a link manager to drive traffic to monetised content, the kind of person who’d use LinkVine to consolidate their social media links and manage how they direct followers to paid products, are operating in a space CONNECT specifically monitors. None of that is illegal. Declaring the income properly is all that’s required.

    The architecture of CONNECT means the risk isn’t about being found doing something wrong. It’s about anomalies. If your public-facing activity signals a scale of commercial operation that your tax return doesn’t reflect, a flag gets raised. That’s the system working as designed.

    The Broader Data Architecture Picture

    From a pure data engineering perspective, CONNECT is impressive. It’s a large-scale ETL (extract, transform, load) pipeline feeding into a risk model, running across a distributed data store with graph traversal capabilities. The refresh cadence on third-party feeds varies, some (like RTI from employers) are near real-time, others (like Land Registry) are batch-updated. The machine learning models are retrained periodically against confirmed fraud cases to improve precision and reduce false positives.

    The UK is not alone in building systems like this, comparable platforms exist across OECD member nations, but CONNECT is widely regarded as one of the more mature implementations. It’s been running for over 15 years, has been continuously refined, and is now deeply embedded in HMRC’s compliance strategy. Whether you find that reassuring or unsettling probably depends on whether you’ve ever had a compliance letter drop through your door.

    Frequently Asked Questions

    What is the HMRC CONNECT system and what does it do?

    CONNECT is HMRC’s automated risk-scoring analytics platform that ingests billions of data points from sources including Land Registry records, DVLA, Companies House, banks, and social media to identify taxpayers whose declared income appears inconsistent with their observable lifestyle or assets. It has been operational since around 2010 and is credited with recovering billions in unpaid tax.

    Can HMRC monitor my social media accounts?

    HMRC can and does monitor publicly accessible social media content as part of the CONNECT system’s data profiling operation. They cannot access private messages or locked accounts without a court order, but any public posts, business promotions, or lifestyle content you share openly is fair game under existing UK legal frameworks and has been confirmed as proportionate use of public data by the ICO.

    How does CONNECT decide to trigger a tax investigation?

    CONNECT uses a risk-scoring model that compares your declared income against data from dozens of third-party sources. High-risk scores, generated by anomalies like unexplained property purchases, undeclared rental income, or a mismatch between your business activity and your tax return, push your case to a human compliance officer for review. Not every flag results in an investigation.

    Can I find out what data HMRC holds on me through CONNECT?

    You can submit a Subject Access Request to HMRC under UK GDPR, but HMRC applies significant exemptions when disclosure might compromise an investigation or prejudice law enforcement activity. In practice, the system’s internal risk scores and data feeds are not typically disclosed, even in response to a valid SAR.

    Does CONNECT target small traders more than large corporations?

    The data signals for small businesses and self-employed individuals tend to be stronger and more consistent, making CONNECT particularly effective in this segment. Large corporate tax avoidance involves more complex, often technically legal structures that are harder to model algorithmically. However, CONNECT does also process high-net-worth individuals and offshore financial data via Common Reporting Standard feeds.

  • Dark Patterns at Scale: How UK Retail and Subscription Sites Are Technically Engineered to Manipulate You

    Dark Patterns at Scale: How UK Retail and Subscription Sites Are Technically Engineered to Manipulate You

    There’s a whole discipline of front-end engineering that nobody puts on their CV. It lives in the gap between UX and manipulation, and it’s been running quietly on thousands of UK retail and subscription sites for years. We’re talking about dark patterns: the deliberately broken flows, the guilt-trip copy, the countdown timers that reset when you reload the page. These aren’t design accidents. They’re code decisions made by real developers, pushed to production, and left to harvest consent and cash from users who don’t know any better.

    The ICO has been watching. In 2025, it published updated enforcement guidance specifically targeting dark patterns under UK GDPR, and for the first time it stopped treating these patterns as vague compliance concerns and started treating them as technical violations. That changes the conversation significantly. If you’re a developer, a tech lead, or just someone who enjoys pulling back the curtain on how this stuff actually works, this one’s worth understanding properly.

    Anonymous developer inspecting dark patterns UK websites ICO enforcement using browser developer tools
    Anonymous developer inspecting dark patterns UK websites ICO enforcement using browser developer tools

    What dark patterns UK websites ICO enforcement actually covers

    The ICO’s 2025 guidance, updated following its earlier cookie consent work, makes clear that dark patterns affecting consent are unlawful under UK GDPR Articles 4(11) and 7. Consent must be freely given, specific, informed, and unambiguous. Any interface design that nudges, pressures, or tricks users into consenting to something they wouldn’t otherwise agree to fails that test. The guidance explicitly references cookie banners, subscription sign-ups, and marketing opt-ins as areas under active scrutiny.

    What makes this interesting from a technical standpoint is that the ICO isn’t just looking at policy language anymore. It’s looking at the actual rendered interface, including pre-ticked boxes in the DOM, asymmetric button styling, misleading label associations in form elements, and yes, fake urgency timers. You can read the guidance directly on the ICO’s website. It’s surprisingly readable for a regulatory document.

    Pre-ticked checkboxes: the oldest trick in the DOM

    This one should be dead. UK GDPR has prohibited pre-ticked consent boxes since it came into force, but they keep appearing. The implementation is trivially simple, which is probably why developers keep shipping it.

    A checkbox with checked="checked" in the HTML, or defaultChecked={true} in React, placed next to marketing consent copy, is not a grey area. It’s an explicit violation. The pattern survives because enforcement has historically been slow and because A/B tests routinely show that pre-ticked boxes increase opt-in rates dramatically, sometimes by 60-70% compared to unchecked defaults. That’s the commercial incentive sitting right there in plain numbers, and it’s why product managers keep asking for it.

    The workaround some sites attempt is to dynamically tick the box via JavaScript after page load, presumably hoping it looks cleaner in an audit of the HTML source. It doesn’t matter. The ICO’s technical assessors look at rendered state, not just source markup.

    Close-up of a pre-ticked consent checkbox representing dark patterns UK websites ICO enforcement concerns
    Close-up of a pre-ticked consent checkbox representing dark patterns UK websites ICO enforcement concerns

    Countdown timers and manufactured urgency

    Fake countdown timers are a proper bit of engineering nastiness. The basic version is a JavaScript timer that displays decreasing seconds to create urgency around an offer: “Offer expires in 04:32”. The timer hits zero. Nothing happens. You reload. Timer resets. The offer never actually expires because it was never real.

    Slightly more sophisticated versions persist the timer value in localStorage or a session cookie, so it looks consistent within a single session but resets whenever you clear your browser data or return a week later. Some implementations use a server-side timestamp with a hardcoded end date that just keeps getting updated via a CMS. It’s the same lie told in slightly different technical dialects.

    Under the Consumer Protection from Unfair Trading Regulations 2008 (which runs alongside UK GDPR on commercial practices), creating a false impression about the availability of a product or the time-limited nature of an offer is an unfair commercial practice. The ICO’s 2025 guidance ties this directly to the consent context, but the Trading Standards angle means retailers face exposure from multiple directions simultaneously. The CMA has also been increasingly active here.

    Confirm-shaming: weaponised copy in button labels

    Confirm-shaming is the practice of labelling the decline option in a way that makes users feel stupid or bad for not accepting. Classic example: a newsletter pop-up where “Yes, sign me up!” sits next to “No thanks, I don’t want to save money.” The asymmetry is the manipulation. One option is framed positively, the other with implied self-criticism.

    From a code perspective this is just a string in a button element, but the ICO’s guidance specifically addresses this pattern under the requirement that refusing consent must be as easy as giving it, and must not carry any penalty or negative framing. A button label that guilt-trips a user into accepting consent fails the freely given test. That’s the legal argument. Whether enforcement catches up with every site doing this is a different question, but the legal exposure is real.

    Cancellation flows: deliberate friction by design

    This is where the engineering gets genuinely creative in a grim sort of way. Subscription cancellation flows are sometimes architected to be as painful as possible. Multi-step flows that require you to navigate four or five pages. Cancellation buttons that are styled to look disabled. “Pause instead of cancel” pre-selected by default. Customer service chat triggers that intercept the cancellation intent and route to a human retention agent before the user can complete self-service cancellation.

    I’ve personally audited a cancellation flow for a UK streaming service (no names, but it rhymes with a popular hobby) that had nine distinct steps between clicking “Manage subscription” and receiving confirmation of cancellation. Each step offered an alternative. Most steps had a prominent “Keep my subscription” button and a much smaller, lower-contrast “Continue cancelling” link in grey text. This wasn’t an accident. That was A/B tested and optimised. Someone wrote those CSS classes deliberately.

    The ICO’s updated guidance treats deliberately burdensome withdrawal of consent as equivalent to making consent hard to withdraw in the first place, which it is required to be easy under Article 7(3). For paid subscriptions, the Direct Debit Guarantee and FCA consumer duty rules add further layers of exposure. The legal net is getting tighter.

    What actually changes under the 2025 ICO guidance

    The practical shift in the 2025 guidance is that the ICO has started issuing reprimands and fines tied specifically to interface design rather than just policy-level failures. Earlier enforcement actions tended to focus on things like no privacy policy at all, or data transfers without adequate safeguards. Now the ICO is looking at the rendered consent interface as a technical artefact subject to GDPR compliance testing.

    For development teams, this means consent flows need to be treated with the same rigour as security controls. Accessibility testing frameworks like axe or Lighthouse can flag some structural issues, but a proper dark pattern audit requires someone who understands both the regulatory requirements and the front-end implementation. That’s a rare combination, which is part of why so many sites are still getting away with this.

    The realistic risk profile for most UK sites is still low in terms of active enforcement, but that’s changing. The ICO’s 2025 report on cookie compliance found that a significant proportion of the top UK retail sites still use non-compliant consent mechanisms. Regulators tend to start with high-profile targets and work down. If you’re building something that touches user consent, now is the time to clean it up rather than wait for a letter from Wilmslow.

    How to spot these patterns in the wild

    Open DevTools. Check the DOM state of any checkbox labelled with consent copy before you interact with the page. Look at button styles for asymmetric prominence on accept vs. decline actions. Run a network request trace on a countdown timer to see if there’s a server call setting the end time, or whether it’s just a local JavaScript interval with no backing reality. Inspect the cancellation flow in a subscription’s account management section and count the steps. These things are all visible if you know where to look.

    Dark patterns at scale aren’t some shadowy conspiracy. They’re just incentive structures playing out in code. Product metrics reward conversion. Dark patterns improve conversion numbers. Developers implement what they’re asked to build. The ICO’s enforcement push is the external pressure that changes that calculus, and it’s about time it did.

    Frequently Asked Questions

    Are dark patterns illegal in the UK?

    Some dark patterns are explicitly illegal under UK GDPR, particularly those affecting consent mechanisms like pre-ticked boxes or burdensome cancellation flows. Others may breach the Consumer Protection from Unfair Trading Regulations 2008. The ICO’s 2025 enforcement guidance has made the legal position significantly clearer.

    What has the ICO done about dark patterns on UK websites?

    The ICO updated its enforcement guidance in 2025 to specifically address dark patterns as technical GDPR violations rather than just policy-level concerns. It has issued reprimands and fines tied to the design of consent interfaces, and its 2025 cookie compliance report flagged a large number of UK retail sites as non-compliant.

    Can a pre-ticked checkbox on a UK website get a company fined?

    Yes. Pre-ticked consent checkboxes have been explicitly prohibited under UK GDPR since it came into force, as consent must be an unambiguous affirmative action. The ICO can issue enforcement notices and fines for this, and the 2025 guidance makes clear that dynamically ticked boxes via JavaScript carry the same liability.

    What counts as a fake countdown timer under UK consumer law?

    A countdown timer that resets, never actually expires, or references an offer that is permanently available creates a false impression about product availability. This can breach the Consumer Protection from Unfair Trading Regulations 2008 as well as UK GDPR consent requirements if used in a consent context. Trading Standards and the CMA both have enforcement powers here.

    How do I report a UK website using dark patterns?

    You can report consent-related dark patterns to the ICO via its online complaints tool at ico.org.uk. For misleading commercial practices like fake urgency timers or confirm-shaming in a sales context, you can report to Citizens Advice, who refer complaints to Trading Standards. The CMA also has an online reporting tool for unfair commercial practices.

  • How Attackers Are Abusing UK Companies House Data for Corporate Identity Fraud

    How Attackers Are Abusing UK Companies House Data for Corporate Identity Fraud

    Companies House is one of the most open, searchable, and frankly underestimated attack surfaces in the UK. Every limited company registered in England and Wales has its director names, registered addresses, filing histories, and Person of Significant Control (PSC) data sitting there, publicly indexed, free to access, zero authentication required. That transparency is the point. It keeps British business accountable. It also hands attackers a ready-made dossier on almost any company they want to impersonate.

    This is not a theoretical threat. Companies House corporate identity fraud costs UK businesses tens of millions of pounds annually, and the attack patterns are getting sharper as more criminals learn to chain open data together. Let’s walk through exactly how it works, what the OSINT workflows look like from the attacker’s perspective, and what you can actually do about it.

    Anonymous hacker researching Companies House corporate identity fraud on multiple screens in a dark room
    Anonymous hacker researching Companies House corporate identity fraud on multiple screens in a dark room

    What Data Is Actually Exposed on Companies House?

    Go to Companies House Search right now and look up any active limited company. You’ll find the registered office address, the names of every current and past director, their partial dates of birth, their correspondence addresses (often a home address if they filed without a registered agent), the full filing history going back years, a list of people with significant control and their nationality and country of residence, and the company’s SIC code, incorporation date, and share structure. All of it. No API key. No login. No rate limiting worth mentioning.

    For a legitimate researcher or a due-diligence team, this is gold. For a fraudster building a convincing impersonation package, it’s essentially a target profile handed to them on a plate.

    The Three Main Attack Patterns

    1. Invoice Fraud and Business Email Compromise

    An attacker identifies a supplier your company uses. One quick Companies House lookup confirms the supplier’s registered address, directors’ names, and the approximate scale of the business from filing history. They register a lookalike domain, craft an email that references the real director by name and the real company number, and send your accounts payable team a “remittance update” notice. The invoice looks legitimate because every verifiable detail is accurate. The only thing that changed is the sort code and account number at the bottom.

    UK Finance reported that authorised push payment (APP) fraud cost UK victims over £460 million in a single recent year, and a significant chunk of that involves exactly this kind of corporate impersonation chain. The Companies House data is often just the first link.

    2. Dormant Company Hijacking

    This one is nastier and more technical. A dormant company, one that was incorporated but never actively traded or hasn’t filed anything substantive in years, still exists on the register. Some of them have useful-sounding names. An attacker can file a change of registered address with Companies House, often with minimal verification, effectively redirecting official correspondence to an address they control. From there, they can attempt to open business bank accounts, apply for credit, or run scams under a legitimate-looking company identity that has a clean, aged filing history.

    Companies House has acknowledged this vulnerability. Their verification reforms under the Economic Crime and Corporate Transparency Act 2023 are designed to tighten this up, but the rollout is phased and plenty of legacy exposure remains.

    3. Director Impersonation for Targeted Phishing

    PSC data is particularly useful for social engineering. If I know you’re listed as a director with 75-100% share ownership, I know you’re probably the decision-maker. I know your name, a partial DOB, and your correspondence address. Pair that with a quick LinkedIn scrape and some basic OSINT chaining through electoral roll aggregators, and I’ve got enough to craft a highly personalised spear-phishing email, or worse, attempt a SIM swap by impersonating you to your mobile network.

    Close-up of hands at keyboard during Companies House corporate identity fraud reconnaissance
    Close-up of hands at keyboard during Companies House corporate identity fraud reconnaissance

    A Practical OSINT Workflow (The Attacker’s Perspective)

    Understanding the workflow is the first step to disrupting it. Here’s the rough sequence a skilled attacker might run:

    • Step 1: Company Search, Companies House free search. Pull company number, filing history, registered address, director list, PSC register.
    • Step 2: Domain Enumeration, Tools like Subfinder or crt.sh to map the target’s real domains. Whois lookups to cross-reference registration addresses with Companies House data.
    • Step 3: Personnel Mapping, LinkedIn, Hunter.io for email format discovery. Cross-reference director names from Companies House with professional profiles.
    • Step 4: Infrastructure Recon, Shodan, Censys, or GreyNoise to fingerprint publicly exposed services. If the target runs their own mail server, that’s potential for domain spoofing if SPF/DKIM/DMARC is misconfigured.
    • Step 5: Attack Assembly, Lookalike domain registration (often using combosquatting: company-invoices.co.uk, companynarne.com). A convincing HTML email template. A fake invoice referencing real company details.

    The whole thing can be done in under an hour by someone who knows what they’re doing. That should make you uncomfortable.

    Worth noting: teams doing legitimate security research sometimes use free SEO tools to map a target’s digital footprint, and those same enumeration techniques overlap heavily with how attackers scope corporate targets online.

    How to Defend Against Companies House-Based Attacks

    Protect Your Own Filing Data

    Directors can apply to suppress their residential address from the public register if it was filed before the option to use a service address became standard. Companies House has a process for this under section 1088 of the Companies Act 2006. If you’re a director and your home address is sitting on the public register, that’s worth sorting urgently.

    Use a registered agent address for your company’s registered office. It costs almost nothing and keeps your real operational address out of the public record. Many UK accountancy firms offer this service.

    Monitor Your Own Company Record

    Companies House offers a free email alert service that notifies you whenever a filing is made against your company number. Turn this on immediately if you haven’t already. If someone attempts to change your registered address or file fraudulent director changes, you’ll know within hours rather than months.

    You can set this up directly at the gov.uk Companies House follow service. Genuinely takes two minutes.

    Train Your Finance Team

    Invoice fraud succeeds because people trust documents that look correct. Your accounts payable team needs a standing rule: any change to supplier bank details requires a verbal confirmation call to a number already held on record, not a number provided in the email. Every time. No exceptions. This single control stops the majority of BEC attacks cold.

    Harden Your Email Infrastructure

    Publish a strict DMARC policy (p=reject). Enforce SPF and DKIM. Check your domain on MXToolbox if you’re unsure of your current posture. Lookalike domains are far less effective when your legitimate domain has proper email authentication, because it creates a visible discrepancy in email headers that a trained eye, or a decent mail gateway, will flag.

    The Bigger Picture: Open Data and Open Abuse

    There’s a genuine tension here. Companies House transparency is a feature, not a bug. It enables journalism, due diligence, anti-corruption work, and academic research. The Global Legal Entity Identifier Foundation and various anti-money-laundering frameworks actively rely on this kind of open corporate data. Shutting it down is not the answer and is not going to happen.

    The answer is awareness, verification culture, and better identity assurance on the Companies House platform itself. The Economic Crime and Corporate Transparency Act 2023 introduced identity verification requirements for directors, which is a meaningful step. But legislation moves slowly and attackers adapt quickly.

    Companies House corporate identity fraud will keep being a viable attack vector as long as organisations treat the register as something that happens to them passively rather than an active part of their attack surface. Monitor it. Harden it. Train your people. The data is public. What you do with that knowledge is the variable.

    Frequently Asked Questions

    How do fraudsters use Companies House data to commit fraud?

    Fraudsters pull director names, registered addresses, and company numbers from the public register to build convincing impersonation packages. They use this data to craft fake invoices, set up lookalike domains, or attempt to hijack dormant company identities by filing fraudulent changes with minimal verification.

    Can I remove my home address from Companies House?

    Yes. Under section 1088 of the Companies Act 2006, directors can apply to suppress a residential address from the public register. Going forward, you should always use a service address (such as a registered agent or accountant’s address) rather than your home address when filing.

    What is dormant company hijacking and how does it work?

    Dormant company hijacking involves an attacker filing a change of registered address for a dormant but legitimately incorporated company, redirecting official mail to an address they control. They can then attempt to open bank accounts or obtain credit under that company’s aged, clean-looking identity.

    How can businesses protect themselves from Companies House-related invoice fraud?

    The most effective control is a strict policy of verbally confirming any bank detail changes with a supplier using a phone number already on file, never one provided in an email. Combining this with DMARC email authentication and staff training significantly reduces the risk.

    Does Companies House notify you if someone files against your company?

    Yes. Companies House offers a free email alert service that sends a notification whenever a filing is made against a specific company number. You can set this up via the gov.uk follow service, and it’s one of the simplest defensive measures available to any UK company director.

The Latest