The Dark Army

Author: Ethan Miller

  • CAN Bus Hacking in 2026: How UK Researchers Are Exposing the Attack Surface Inside Modern Cars

    CAN Bus Hacking in 2026: How UK Researchers Are Exposing the Attack Surface Inside Modern Cars

    Modern cars are computers that happen to have wheels. That’s been true for a while, but the attack surface in 2026 is genuinely alarming, dozens of ECUs, telematics boxes, Bluetooth stacks, LTE modems, and a single shared bus topology that was designed in the 1980s when nobody thought a vehicle would ever be network-connected. I’ve been watching UK security researchers dig into this space for the last couple of years, and the findings are uncomfortable reading for manufacturers, regulators, and anyone who owns a relatively recent car sold on British roads.

    OBD-II port under dashboard used in CAN bus hacking research
    Photo by Daniel Andraski on Pexels

    What the CAN bus actually is and why it’s a problem

    The Controller Area Network (CAN) protocol was developed by Bosch in 1983 and standardised as ISO 11898. It lets microcontrollers inside a vehicle talk to each other without a host computer in the middle. Your engine management unit, your ABS controller, your dashboard cluster, your steering column, they all broadcast short frames onto the same wire, and every node on the bus reads every frame. There’s no authentication. There’s no encryption. Any node can spoof any other node. The original assumption was physical isolation: if you’re inside the car and on the bus, you’re trusted.

    That assumption collapsed the moment vehicles got OBD-II ports (mandatory on UK petrol cars from 2001 under EU regulations, now retained under UNECE type-approval rules carried over into UK law post-Brexit), Bluetooth dongles, Wi-Fi hotspots, and over-the-air update channels. The bus is still the same fundamentally insecure topology, but now there are bridges from the outside world straight onto it. That’s CAN bus hacking in its simplest framing: you find a path to the bus, and then you own every node on it.

    OBD-II port exploitation: the hole under your dashboard

    The OBD-II port is the easiest entry point. It’s physically accessible, it’s mandated by law, and it connects directly to the CAN bus. Mechanics use it. MOT testers use it. Insurance telematics boxes plug into it. So do a huge number of cheap Bluetooth and 4G dongles sold on the high street and via marketplaces like Amazon UK.

    Security researcher Ken Munro at Pen Test Partners (a Buckinghamshire-based firm that has done some of the most serious vehicle security work in the UK) has demonstrated repeatedly that poorly secured OBD dongles can be compromised over Bluetooth from outside the vehicle. Once you have a shell on the dongle, you’re issuing raw CAN frames. At that point you can spoof sensor readings, suppress fault codes, or in more serious cases, influence safety-critical systems depending on the vehicle architecture. The research has been published openly, and the NCSC has referenced this class of attack in its guidance on connected vehicle security.

    What makes this worse in 2026 is the secondhand market. Cars change hands, but the telematics box the previous owner used for cheaper insurance often stays plugged in. I’ve seen three separate threads on UK automotive forums where buyers found active insurance dongles still live and broadcasting on a car they’d just bought. That’s an attacker’s dream: a persistent, internet-connected bridge to the CAN bus, and the current owner doesn’t even know it’s there.

    Over-the-air update interception and firmware integrity

    OTA updates are where things get genuinely interesting. Every mainstream manufacturer now pushes firmware updates to ECUs wirelessly. Tesla has done it longest, but Ford, BMW, Volkswagen Group, and Stellantis brands are all doing it on models sold in the UK. The update mechanism typically involves a telematics control unit (TCU) with an LTE modem that pulls a signed firmware image from a manufacturer’s backend, verifies a signature, and then flashes the target ECU over the internal bus.

    The signing is usually RSA or ECDSA, and when it’s implemented properly, intercepting the download gives you an encrypted blob you can’t do much with. The problem is implementation. Researchers at the University of Birmingham published work in 2023 demonstrating that several manufacturers’ TCUs would accept updates over unencrypted HTTP under specific fallback conditions, and that certificate pinning was either absent or bypassable with a compromised root CA. A man-in-the-middle on the vehicle’s Wi-Fi or a rogue 4G cell (a cheap software-defined radio setup can fake a cell tower well enough to catch an LTE data session) puts an attacker in a position to serve a malicious firmware image, provided they can also forge or strip the signature check.

    UK UNECE Regulation 156, which covers software update processes and has been legally binding on new UK type-approvals since 2022, requires manufacturers to document their software update management systems and have them audited. It does not specify cryptographic standards in granular detail. That gap is where researchers are finding the interesting stuff.

    Reverse engineering proprietary firmware with open-source tools

    Getting firmware off an ECU is a prerequisite for most serious research. The common approaches in the UK security community right now involve JTAG and SWD debugging interfaces (often physically present on the PCB but with fuses blown or debug-lock bits set), flash chip extraction using a hot-air rework station and an SP flash programmer, and occasionally exploiting bootloader vulnerabilities to dump memory over an existing interface like the CAN bus itself via diagnostic protocols (UDS on ISO 14229).

    Once you have a binary, the toolchain looks familiar to anyone who does embedded reverse engineering. Ghidra (the NSA-released disassembler, now widely used by UK researchers) handles most architectures you’ll find in automotive ECUs, Renesas RH850, Infineon TriCore, NXP S32. Binwalk identifies filesystem structures. Custom Python scripts parse proprietary calibration maps. The ECU remapping community has actually done a huge amount of groundwork here: people who tune engines for performance have been extracting and modifying ECU firmware for years, and their tooling overlaps significantly with what security researchers use. Sites like fastandfurious4.co.uk sit squarely in the performance car world where ECU remapping is part of the culture, and that culture has produced engineers who understand firmware internals better than most professional security teams do.

    The open-source tool getting the most attention right now is OpenXC combined with python-can, which lets researchers log and replay CAN frames cheaply using a Raspberry Pi and a MCP2515 module (total hardware cost: under £20 from any UK electronics supplier). Couple that with CANalyze or SavvyCAN for traffic analysis, and you have a working lab for CAN bus research. The barrier to entry is genuinely low, which is both democratising for legitimate researchers and concerning for threat actors.

    For context on how physical infrastructure security intersects with digital systems in UK transport, it’s worth reading about how smart motorway speed limits interact with connected car systems, because variable speed enforcement increasingly relies on data from the vehicles themselves, creating feedback loops that don’t exist in traditional road infrastructure.

    The regulatory picture and where UK researchers fit in

    UNECE Regulation 155 (cybersecurity management systems) and Regulation 156 (software updates) are the backbone of vehicle cybersecurity law for new UK type-approvals. The Vehicle Certification Agency handles type-approval in Great Britain. These regulations require manufacturers to maintain a cybersecurity management system throughout the vehicle lifecycle, conduct threat analysis and risk assessments (TARA), and monitor for new threats post-production. In practice, the auditing is paper-heavy and the monitoring is largely self-reported.

    UK researchers who find vulnerabilities face the same disclosure problem that exists across the industry. There’s no equivalent of the NCSC’s coordinated vulnerability disclosure process for automotive systems, which is already imperfect for software infrastructure, and manufacturers’ own disclosure programmes are inconsistent. Some pay bounties. Some send legal letters. The UK’s cybercrime reporting infrastructure is not designed for this class of finding. So most serious automotive research ends up going through academic channels, conference papers (Escar Europe is the main venue), or via firms like Pen Test Partners who have the manufacturer relationships to get findings acted on.

    The Vehicle Technology and Aviation Bill (currently in parliamentary committee as of mid-2026) touches on automated vehicle liability but is largely silent on active cybersecurity obligations for existing vehicles. The gap between what UNECE 155/156 requires on paper and what actually gets tested on production hardware is significant, and the UK security research community is filling it faster than the regulator is.

    My read on where this goes: the attack surface gets worse before it gets better. More connectivity, more OTA updates, more third-party apps and dongles, same underlying CAN topology. Vehicle-to-everything (V2X) communication, which UK trials are already running on the A2 and M25 corridors, adds another radio interface to the mix. The researchers doing this work, often working from homelabs with sub-£100 hardware, are the reason any of this gets fixed at all. The pattern of researchers finding what institutional security misses is consistent across every technical domain. Automotive is no different.

    The NCSC’s connected vehicle security guidance is publicly available at ncsc.gov.uk and worth reading if you want the official framing, even if the practical reality in 2026 is considerably messier than the guidance implies.

    Frequently Asked Questions

    What is CAN bus hacking and how does it work on modern cars?

    CAN bus hacking exploits the Controller Area Network, the internal communications protocol that lets ECUs inside a vehicle talk to each other. Because the protocol has no authentication or encryption, anyone with access to the bus, via the OBD-II port, a compromised telematics dongle, or an OTA update channel, can read all traffic and inject spoofed frames that other nodes will act on.

    Is accessing a car's CAN bus via the OBD-II port legal in the UK?

    Plugging into your own car’s OBD-II port is legal. Using that access to interfere with vehicle systems in a way that makes the car unsafe or to commit fraud is a criminal offence under the Computer Misuse Act 1990 and road traffic legislation. Security researchers working on vehicles they own, or with explicit owner consent, occupy a legally grey but generally accepted space provided they disclose responsibly.

    Can over-the-air updates be intercepted to push malicious firmware to a car?

    In theory, yes, and researchers have demonstrated it in controlled conditions. Properly implemented OTA systems use cryptographically signed firmware that an ECU will verify before flashing. The risk lies in weak implementations: absent certificate pinning, unencrypted fallback channels, or signature verification that can be bypassed. UNECE Regulation 156 requires manufacturers to document their update security, but independent testing of production systems is limited.

    What tools do UK researchers use to analyse CAN bus traffic?

    Common tools include python-can and SavvyCAN for logging and replaying CAN frames, a Raspberry Pi with an MCP2515 module as cheap hardware, and Ghidra for firmware reverse engineering once a binary has been extracted. Total hardware cost for a basic CAN research setup is under £20. More advanced work involves JTAG extraction and UDS/ISO 14229 diagnostic protocol fuzzing.

  • Crypto Drainers Targeting UK Investors: How Wallet-Emptying Smart Contracts Are Being Disguised as HMRC Tax Tools and FCA-Registered Platforms

    Crypto Drainers Targeting UK Investors: How Wallet-Emptying Smart Contracts Are Being Disguised as HMRC Tax Tools and FCA-Registered Platforms

    There’s a particular breed of scam doing the rounds right now that I find genuinely impressive in how nasty it is. Not admirable, to be clear. But the engineering is sharp, the social engineering sharper, and the targets are ordinary British retail investors who’ve done everything right, declared their crypto, tried to stay compliant, and got robbed anyway. The crypto drainer scam UK HMRC FCA combo is the current peak of that particular racket, and it’s worth understanding exactly how it works.

    Anonymous hacker figure at monitors in a crypto drainer scam UK HMRC FCA campaign setup
    Photo by Sora Shimazaki on Pexels

    What a crypto drainer actually is

    A drainer isn’t a phishing page that steals your seed phrase. That’s old-school. A drainer is a malicious smart contract, usually deployed on Ethereum or a cheap EVM-compatible chain like Base or Polygon, that you authorise yourself. One transaction. One signature. Everything gone.

    The flow is simple in concept. The attacker deploys a contract with a function that calls transferFrom on every ERC-20 token in your wallet, plus sweeps native ETH, once you’ve granted approval. The contract often bundles these into a single multicall so the drain completes atomically. If you sign the approval, the contract does the rest without any further input from you or the attacker. Etherscan will cheerfully show you the transaction you authorised. The funds are gone in seconds, typically bridged and tumbled within minutes.

    Drainer kits, pre-built, ready to deploy, have been selling on Telegram and dark web forums since at least 2023. By 2026, they’re subscription services. Some charge a flat monthly fee; others take 20–30% of everything drained. There are support channels, changelogs, even feature requests. It’s a genuinely functional criminal SaaS ecosystem.

    The HMRC angle: why it’s so effective against UK investors

    Here’s where it gets specifically British. HMRC treats crypto as a capital asset, which means UK retail investors have real, ongoing tax obligations, capital gains on disposals, income tax on staking rewards, and a Self Assessment deadline that makes people anxious every January. That anxiety is the attack surface.

    The campaigns I’ve been tracking follow a consistent pattern. A UK investor searches for something like “HMRC crypto tax calculator 2025-26” or “how to report crypto gains UK”. They land on a site that looks like a professional tax tool, clean UI, GOV.UK-adjacent colour scheme, the HMRC logo (lifted directly, obviously), and a table showing allowances and rates that are actually accurate. The accuracy matters. It builds trust.

    Then comes the hook. To generate your “personalised tax report” or “portfolio gain summary”, the tool asks you to connect your wallet. This is framed as read-only, just so the tool can see your holdings and calculate gains automatically. That framing is a lie. The wallet-connect flow that follows requests a signature that isn’t read-only at all. It’s an approval transaction, or in some cases a permit signature (EIP-2612), which requires no on-chain transaction from you, just an off-chain signature that the drainer contract can then use to pull funds.

    Spoofed FCA registration numbers

    The second layer of the crypto drainer scam UK FCA attack is spoofing the Financial Conduct Authority’s register. This one is brazen. The FCA’s Financial Services Register is public, anyone can look up a firm’s registration number at register.fca.org.uk. Attackers take real FCA registration numbers from legitimate, inactive, or recently dissolved crypto asset firms and paste them onto their fake platforms.

    Most retail investors don’t verify these properly. They see “FCA Registered: 123456” in the footer, search that number, find a result on the FCA register, and stop there. They don’t check whether the firm name matches, whether the registration covers the specific activity advertised, or whether the firm is listed as “Cancelled” or “Removed”. The FCA register UI doesn’t exactly make this obvious at a glance.

    I’ve seen at least three campaigns in 2026 using registration numbers belonging to firms that surrendered their authorisation, meaning the number exists in the register but the firm is no longer permitted to operate. Technically accurate enough to pass a quick look. Technically fraudulent in every meaningful sense.

    The FCA does maintain a Warning List of known unauthorised firms, and some of these drainer sites do end up there eventually. But the campaigns burn through domains fast, similar to how UK phishing infrastructure rotates through .uk and .co.uk domains before takedown catches up. A site lives for a week, drains a few wallets, disappears.

    The wallet-connect flow in technical detail

    Let’s get into the mechanics, because understanding this is the only real defence.

    When a legitimate DeFi protocol uses WalletConnect or a browser wallet like MetaMask, it sends a JSON-RPC request to your wallet asking for a signature or transaction approval. The wallet UI shows you what you’re signing. The problem is that most users have been trained to click through these prompts, and drainer sites exploit that conditioning brutally.

    The specific techniques vary. Some drainers request eth_sign on arbitrary data, which some wallet implementations will sign without showing readable context. Others use personal_sign with a blob that looks like a random hash but is actually a structured message that the contract can verify on-chain. The most sophisticated use EIP-712 typed data signing, which does show structured fields in the wallet UI, but labels them with innocuous names like “TaxReport”, “PortfolioID”, or “ConsentHash”.

    The permit approach is particularly nasty because it leaves no on-chain trace until the attacker redeems the signature. You sign something off-chain, nothing happens immediately, and you walk away thinking the tool just didn’t work. Then, hours later, the attacker submits the permit transaction and the drain executes. By the time you notice, the transaction trail has been routed through a mixer.

    This connects to a broader pattern of how credential and approval theft works across the UK attack surface, similar social engineering mechanics appear in SIM swap fraud targeting UK banking 2FA, where the goal is always to get the victim to perform a legitimate action that completes the attacker’s objective.

    Why victims can’t easily get their money back

    This is the part that really stings. Crypto transactions are irreversible by design. There’s no equivalent of a bank chargeback, no Section 75 protection, no FSCS coverage. If you signed the transaction, you signed it. The contract executed correctly from the blockchain’s perspective.

    Action Fraud will take your report. What happens next is, let’s say, not exactly rapid. The NFIB system processes crypto fraud reports but chain analysis and cross-border coordination make recovery genuinely rare. The National Cyber Security Centre has published guidance on crypto scams, but prevention messaging doesn’t help people who’ve already lost funds.

    Some victims have had partial success contacting exchanges where drained funds were cashed out, if the attacker made the mistake of using a KYC’d exchange, a police production order can sometimes freeze an account. But drainer operators are rarely that careless. Funds typically hit a bridge, then a DEX swap, then a privacy protocol, within one automated script execution.

    How to spot and avoid these drainer campaigns

    A few concrete things that will actually help. First: no legitimate HMRC tool, tax calculator, or GOV.UK service will ever ask you to connect a crypto wallet. Ever. HMRC calculates tax from figures you provide, not by reading your wallet directly. If something is asking for a wallet connection in a tax context, it’s a drainer. Full stop.

    Second: check FCA registrations properly. Don’t just search the number. Verify the firm name matches exactly, check the registration status is “Authorised” (not Cancelled or Removed), and check that the specific permission listed covers what the site claims to do. Crypto asset firms registered under the Money Laundering Regulations have a separate register entry from those with full FCA authorisation, and the distinction matters.

    Third: read wallet prompts. Actually read them. MetaMask and most modern wallets now flag high-risk signature types. If you see a warning about unlimited token approvals or permit signatures, stop. No tax tool needs that.

    Fourth: use a hardware wallet for anything significant. Ledger and Trezor devices display the full transaction data on a separate screen, much harder to slip malicious approval requests past a user who’s looking at a physical device rather than a browser popup.

    The NCSC’s vulnerability disclosure and threat intelligence functions are increasingly aware of drainer campaigns, similar to the infrastructure monitoring described in the GCHQ NCSC disclosure process, but drainer sites move faster than takedown processes. The defence has to start with the individual. Know what you’re signing.

    Frequently Asked Questions

    What is a crypto drainer and how is it different from regular phishing?

    A crypto drainer is a malicious smart contract that empties your wallet after you sign a single approval transaction. Unlike phishing, which steals your seed phrase or password, a drainer works entirely through legitimate blockchain mechanics, you authorise it yourself, which is why it’s so hard to reverse or dispute.

    Are fake HMRC crypto tax calculator sites easy to spot?

    Not always, which is the problem. The better-built ones use accurate tax rates, credible-looking GOV.UK-style design, and real HMRC logos. The giveaway is the wallet-connect requirement, no genuine HMRC or tax tool will ever ask you to connect a crypto wallet to calculate your gains.

    How do I check if an FCA registration number is legitimate?

    Go directly to register.fca.org.uk and search the number. Check that the firm name on the register exactly matches the site you’re looking at, that the status shows ‘Authorised’ (not Cancelled or Removed), and that the specific permissions listed cover what the platform claims to do. Mismatches on any of these are red flags.

    Can I get my money back if a crypto drainer steals my funds?

    Realistically, recovery is very rare. Crypto transactions are irreversible and there’s no FSCS protection or chargeback mechanism. You can report to Action Fraud and the FCA, and in some cases police can freeze exchange accounts via production orders if the attacker used KYC’d platforms, but most drainer operators route funds through mixers and DEX swaps within minutes.

    What wallet settings or tools can protect me from drainer attacks?

    Use a hardware wallet like Ledger or Trezor for any significant holdings, they display full transaction details on a separate screen. In MetaMask, pay attention to approval warnings and never grant unlimited token approvals to unfamiliar contracts. Browser extensions like Revoke.cash let you audit and revoke existing approvals that you may have granted previously.

  • Inside GCHQ’s NCSC Vulnerability Disclosure Process: What Actually Happens When a Researcher Reports a Critical UK Infrastructure Bug

    Inside GCHQ’s NCSC Vulnerability Disclosure Process: What Actually Happens When a Researcher Reports a Critical UK Infrastructure Bug

    You’ve found something. A memory corruption bug in software running across NHS trusts, or an authentication bypass in a platform used by three government departments. You’ve documented it, written a clean proof-of-concept, and you’re sitting there wondering whether to report it through official channels or just post it on a forum and watch the chaos unfold. If you go the responsible route and report to the NCSC, here’s what actually happens, because the official documentation paints a tidy picture that doesn’t quite match what researchers describe on the other side.

    Researcher in dark room reviewing code related to NCSC vulnerability disclosure UK process
    Photo by Rafael Minguet Delgado on Pexels

    The NCSC’s coordinated vulnerability disclosure framework, explained

    The NCSC operates the UK’s central coordinated vulnerability disclosure (CVD) process, sitting underneath GCHQ in Cheltenham. The framework is modelled loosely on international standards, ISO/IEC 29147 for disclosure and 30111 for handling, but adapted for the UK’s specific mix of government systems, critical national infrastructure, and private sector tech. The idea is straightforward: researcher finds bug, researcher reports to NCSC, NCSC contacts the affected vendor or department, everyone agrees a remediation timeline, and a public advisory goes out once a patch exists. Clean. Orderly. In theory.

    The NCSC’s vulnerability reporting page gives you an online submission form plus a PGP key for encrypted reports. You can also email them directly. First contact is supposed to trigger an acknowledgement within two working days, and from what I’ve seen, they’re pretty consistent on that front. The triage team reads what you’ve sent, assesses severity using CVSS scoring alongside their own contextual weighting (whether the affected system is CNI, how exploitable it is in the wild, whether there’s active threat actor interest), and then decides who owns the fix.

    What the triage process actually looks like

    Here’s where it gets interesting. The NCSC doesn’t fix anything itself. It acts as a broker between the researcher and whoever built or operates the vulnerable system. If you’ve found a bug in a vendor’s product, say, a popular enterprise VPN client used across the public sector, the NCSC will contact that vendor and attempt to coordinate a fix timeline. If you’ve found something in a government-owned system, the process routes internally, sometimes through the Cabinet Office or the relevant department’s own technical security team.

    The target remediation window is 90 days. That’s not a hard deadline in law, but it’s the standard the NCSC applies before considering whether to advise on limited public disclosure. Some researchers I’ve spoken to say the 90-day window is generally respected, especially for high-severity findings. Others describe situations where a government department has essentially stonewalled the process, citing operational constraints, procurement cycles, or, and this comes up more than you’d expect, the fact that fixing the vulnerable component would require replacing an entire legacy system they don’t have budget to touch.

    Where the process breaks down

    The biggest friction point isn’t the NCSC itself, most researchers say the team is technically competent and genuinely motivated. The problem is the handoff. Once the NCSC contacts an affected department or vendor, the researcher is largely cut out of the loop. You submit your report, get a case reference, and then wait. The NCSC won’t necessarily tell you what the vendor said, whether they’ve accepted the severity rating, or what the remediation plan looks like. That opacity is deliberate, the NCSC is trying to keep lines of communication open with vendors, and looping a researcher into every exchange would complicate that, but from the researcher’s side it can feel like your report vanished into a void.

    This connects to a broader concern about legacy infrastructure. The same class of problems we’ve seen with ransomware groups mapping UK critical national infrastructure, outdated systems, fragmented ownership, no clear party responsible for patching, makes the CVD process genuinely hard to execute. When you can’t identify a single responsible vendor or department for a vulnerability, the broker model struggles. The NCSC has to work out whether it’s talking to a network operator, a software supplier, a managed service provider, or some combination of all three. That takes time, and the 90-day window starts ticking regardless.

    There’s also the question of what counts as a government vulnerability versus a vendor vulnerability. Take something like a misconfigured API endpoint leaking data from a government-contracted SaaS platform. The department didn’t write the code; the vendor is based overseas; the data belongs to UK citizens. Who’s responsible? The NCSC will attempt to coordinate, but it has no legal enforcement power over a foreign vendor. It can apply reputational pressure, escalate to international CERT partners, or advise the department to terminate the contract, but it can’t compel a fix on any timeline.

    The researcher experience: what people actually say

    Bug bounty hunters and independent researchers who’ve gone through the NCSC process have mixed views. The positive feedback clusters around transparency in initial communication, the quality of the triage team’s technical responses, and the fact that the NCSC does issue public advisories when vendors cooperate. The NCSC’s own published advisories are detailed and useful, they’re worth bookmarking if you’re tracking vulnerabilities in UK-deployed software.

    The negative feedback centres on a few recurring themes. One is the absence of bug bounty payments. The NCSC doesn’t pay for vulnerability reports. Full stop. If you’ve spent three weeks reverse-engineering a binary to find a critical flaw in a system protecting public sector data, your reward is a thank-you and a credit in an advisory, if you get even that. Several researchers have told me they’ve moved away from reporting UK government findings to the NCSC because the economics don’t work. They’ll report vendor bugs through the vendor’s own programme where there’s money attached, and only escalate to the NCSC when the vendor ignores them.

    A second issue is status updates. Once your report is in, you might get silence for weeks. The NCSC says it will update researchers on “significant developments”, but significant is doing a lot of work in that sentence. Researchers who’ve reported high-severity bugs describe waiting 40 or 50 days without meaningful updates, unsure whether the vendor is actively patching or has simply deprioritised the finding. This is similar to frustrations documented around other reporting systems, the kind of opacity that also plagues Action Fraud’s NFIB triage process, where reports go in and nothing tangible seems to come out.

    When the NCSC goes public without a patch

    The nuclear option in CVD is publishing a vulnerability advisory before a patch exists. The NCSC will do this, they say so explicitly, if the 90-day window passes without meaningful remediation progress, or if they assess that the vulnerability is already being actively exploited in the wild. In practice, this is rare but it does happen. The NCSC’s vulnerability advisories page carries notices where vendors are named alongside unfixed issues, which creates real commercial and reputational pressure.

    What researchers want is more transparency about how this decision gets made. The NCSC’s public guidance doesn’t specify exactly what threshold triggers forced disclosure. That ambiguity is probably intentional, rigid rules would let vendors game the timeline, but it leaves researchers uncertain about whether their 90-day clock will actually result in disclosure or quietly extend because the affected system is deemed too sensitive to expose publicly. The tension is sharpest around government-operated systems. Disclosing an unpatched vulnerability in, say, infrastructure touching national security would be handled very differently from disclosing one in a third-party vendor’s product.

    What a better process might look like

    A few things would genuinely improve the experience without blowing up the framework. Regular status pings to researchers, even automated ones saying “still in remediation, no change”, would cut the anxiety. Some form of recognition or modest financial acknowledgement for critical findings would bring more serious researchers into the official channel rather than pushing them toward private markets or full disclosure. And clearer published criteria for when the NCSC escalates to forced disclosure would make the 90-day window feel like an actual commitment rather than a rough guide.

    I’d also argue the NCSC could learn something from how the open disclosure community handles complex multi-party vulnerabilities, the kind of coordination issues that show up when, for instance, a single library flaw affects dozens of systems simultaneously. The leaky public repositories problem across NHS and government GitHub accounts is a good example: multiple responsible parties, unclear ownership, and a finding that’s already semi-public by the time anyone reports it formally. The NCSC’s CVD framework wasn’t really designed for that shape of vulnerability, and it shows.

    The framework is worth engaging with. The team is capable and the process, when it works, does result in patches and public advisories that protect real systems. But it’s not the smooth machine the official documentation implies. Go in with realistic expectations, document everything you send, and don’t hold your breath waiting for updates. The bugs you find matter, just don’t expect the process to feel like it knows that.

    Frequently Asked Questions

    How do I report a vulnerability to the NCSC in the UK?

    You can submit a report via the NCSC’s online vulnerability reporting form at ncsc.gov.uk, or email them directly using their published PGP key for encrypted submissions. You should receive an acknowledgement within two working days, along with a case reference number.

    Does the NCSC pay bug bounties for vulnerability reports?

    No. The NCSC does not pay financial rewards for vulnerability disclosures. Researchers may receive credit in a published advisory, but there is no bounty programme. Many researchers report this as a significant barrier to engaging with the official process.

    How long does the NCSC vulnerability disclosure process take?

    The NCSC targets a 90-day remediation window from the point of reporting. In practice, timelines vary considerably depending on the vendor’s responsiveness, the complexity of the fix, and whether the affected system is government-operated. Researchers have reported waits well beyond 90 days without resolution.

  • Inside the UK’s Cybercrime Reporting Black Hole: How Action Fraud’s NFIB System Processes, Triages, and Quietly Buries Your Report

    Inside the UK’s Cybercrime Reporting Black Hole: How Action Fraud’s NFIB System Processes, Triages, and Quietly Buries Your Report

    Every year, hundreds of thousands of people in Britain report being scammed, hacked, or defrauded. They type their details into the Action Fraud portal, click submit, and then… nothing. Maybe an automated email arrives. Maybe a crime reference number. And then silence. I’ve spoken to people who waited eighteen months without a follow-up, people who lost five-figure sums and heard nothing more than a bot acknowledgement. So what is actually happening on the other side of that form? Where does the report go, and why does it so rarely result in anyone being nicked?

    This is a forensic look at the operational and technical pipeline behind Action Fraud and the National Fraud Intelligence Bureau, the NFIB. Understanding Action Fraud NFIB how it works in practice, rather than how the press releases describe it, is genuinely illuminating. And more than a little grim.

    Dark server room representing the Action Fraud NFIB data processing infrastructure for UK cybercrime reporting
    Photo by panumas nikhomkhai on Pexels

    The intake layer: what happens when you submit a report

    Action Fraud is not a police force. That distinction matters more than most people realise. It is operated by the City of London Police under contract, functioning essentially as a national reporting centre. When you file a report through the Action Fraud website or call 0300 123 2040, your data lands in a system called NFIRS, the National Fraud Intelligence Reporting System, which feeds directly into the NFIB’s analysis infrastructure.

    The intake form captures a fairly detailed picture: the type of fraud (there are over 60 sub-categories), dates, monetary loss, suspect details, communication records, and any supporting evidence you upload. Here’s where the first structural problem sits. The quality of what goes in is wildly inconsistent. A technically literate victim might submit server logs, email headers, and a detailed timeline. Someone’s nan who got scammed by a fake parcel delivery text submits “he sounded foreign.” Both go into the same queue and get processed through the same scoring engine.

    NFIB’s intelligence triage: the scoring model that decides your fate

    The NFIB is where actual analysis supposedly happens. Staffed by a mix of civilian intelligence analysts and City of London Police officers, the bureau runs incoming reports through an automated scoring and clustering model before any human eyeballs touch the data.

    The scoring model prioritises reports based on several weighted factors. Monetary value is the most obvious one; a £50,000 investment fraud scores significantly higher than a £200 purchase scam. But the system also looks for what NFIB calls “linkage”, whether a report connects to suspects, phone numbers, bank accounts, or IP addresses already appearing in other reports. This is where the intelligence value actually lives. A single phone number appearing in 400 separate fraud reports is vastly more actionable than 400 isolated incidents.

    The clustering algorithm groups reports by shared indicators of compromise: sort codes, mobile numbers, email domains, IBAN structures, and increasingly, device fingerprints and IP ranges. When a cluster hits a threshold, it nominally triggers escalation to what the NFIB calls a “develop” package, a compiled intelligence package ready for dissemination to a police force. The operative word there is “nominally.”

    Why the majority of reports go nowhere

    Here is the uncomfortable arithmetic. According to data published by the City of London Police and analysed by BBC News, fewer than 1 in 30 fraud reports submitted to Action Fraud results in a charge or summons. Some estimates put the actual investigation rate even lower. The NFIB can only disseminate so many packages, and forces receiving those packages are under no obligation to act on them. A regional force with three economic crime detectives covering an entire county is not going to prioritise a medium-value online fraud when they’re also managing knife crime and county lines.

    The triage scoring model itself creates a structural exclusion zone. Reports below a certain monetary threshold, roughly £1,000 in most cases, are unlikely to generate the kind of linkage data that pushes a cluster into actionable territory quickly enough. They still count toward statistics. They still generate a crime reference number. But in practice, they sit in a database accruing dust unless a future, higher-value report links back to the same suspect infrastructure. I’d argue this is intentional design rather than a bug: the system is optimised to surface organised fraud groups, not to give individual victims any real resolution.

    There’s a parallel worth drawing here. The way NFIB clusters and scores fraud intelligence isn’t entirely unlike how the FCA’s RegTech surveillance pipelines monitor financial markets for manipulation patterns. Both systems look for anomalies across massive data sets and deprioritise low-volume individual signals. The difference is that the FCA’s system has teeth. NFIB’s output depends entirely on under-resourced regional forces choosing to act.

    How data flows to regional forces

    When NFIB decides a cluster is worth packaging, the output goes into what they call an Intelligence Development Package or IDP. This is essentially a structured intelligence product: suspect profiles, linked bank accounts, phone number analysis, victim geography, and a recommended force for action based on suspect or banking location.

    The routing logic for IDPs is fairly straightforward. If suspect bank account details resolve to a branch in West Yorkshire, the package goes to West Yorkshire Police’s economic crime unit. If the fraud infrastructure spans multiple force areas, which is common with organised groups, the package might go to Regional Organised Crime Units (ROCUs), or in serious cases to the National Crime Agency.

    The data format itself has historically been a friction point. NFIB packages were until relatively recently delivered via secure email with PDF attachments rather than API-level data exchange with force case management systems. The Home Office has been pushing for tighter integration, but the reality across 43 forces in England and Wales is that interoperability is patchy. Some forces have invested in fraud case management tooling; others are essentially working off spreadsheets.

    This is also where cross-contamination risks emerge. The same suspect data that NFIB shares with regional forces may also flow to private sector fraud prevention bodies through schemes like CIFAS, the Credit Industry Fraud Avoidance System. Your fraud report data can end up influencing credit decisions and financial services access for third parties connected to suspect profiles, without any of the affected individuals necessarily knowing. That’s a downstream consequence worth thinking about, particularly in the context of how poorly secured data pipelines across government systems can amplify these kinds of unintended exposures.

    The cybercrime gap: what NFIB doesn’t handle well

    Action Fraud NFIB how it works UK cybercrime reporting becomes particularly strained when the crime is technical. Pure cybercrime, unauthorised computer access, malware deployment, DDoS attacks, sits uncomfortably in the Action Fraud taxonomy. The NFIB analysts are mostly trained in financial fraud patterns. A report describing a credential-stuffing attack on a company’s customer database requires a different analytical skill set than a romance fraud cluster.

    The NCSC handles the more serious end of cyber incidents separately, and there’s a real coordination gap between the two bodies. NFIB might receive a report about fraudulent transactions that originated from a compromised account, without ever surfacing the upstream compromise to the NCSC. These two pipelines rarely talk to each other in a structured way. The NCSC’s Early Warning Service is excellent at what it does, but it is not joined up with Action Fraud’s reporting infrastructure at a technical level. That gap is exactly the kind of seam that organised cybercrime groups exploit.

    SIM swap fraud is a decent example of this blind spot in action. The financial loss gets reported to Action Fraud; the underlying telco exploitation that enabled it rarely gets properly triaged as the technical root cause. I’ve covered this pattern in detail when looking at how SIM swap fraud defeats two-factor authentication at the network level. NFIB sees the fraud outcome, not the attack vector.

    What the system is actually built for

    My honest read of the NFIB architecture is that it is designed to produce strategic intelligence about organised fraud, not to provide justice to individual victims. That’s not a criticism without context: you cannot operationally investigate 900,000 fraud reports a year with existing resources. The system makes a triage choice, and that choice is to use victim reports as signal collection rather than case initiation.

    The result is that your Action Fraud submission is, in most cases, feeding a dataset. It helps build the intelligence picture that might eventually take down a fraud group operating out of Eastern Europe or a UK-based money mule network. It contributes to ONS crime statistics. It is useful in aggregate. But for you, as an individual victim who lost money and wants someone held accountable, the system is not really designed to deliver that. Knowing that upfront at least saves you from waiting by the phone.

  • Dissecting the GOV.UK Notify Platform: The API Stack Sending Millions of Official UK Alerts and Why Spoofing It Is Dangerously Plausible

    Dissecting the GOV.UK Notify Platform: The API Stack Sending Millions of Official UK Alerts and Why Spoofing It Is Dangerously Plausible

    Every time your GP surgery texts you a prescription reminder, or HMRC drops you an email about your self-assessment deadline, there’s a good chance that message came through GOV.UK Notify. It’s the Cabinet Office’s centralised messaging platform, quietly powering tens of millions of SMS and email alerts a year across NHS trusts, local councils, the DWP, and more. Most people receiving those messages have no idea it exists. That’s exactly what makes it interesting from a security angle.

    I’ve been pulling apart the Notify API documentation and watching how the platform actually behaves in production. What I found is a well-engineered system with some genuinely smart design choices, sitting inside a trust model that attackers can abuse without touching a single line of Notify’s own code.

    Dark server rack infrastructure powering the GOV.UK Notify API platform
    Photo by Christina Morillo on Pexels

    What GOV.UK Notify actually is

    Notify is a Government Digital Service (GDS) product. Any UK public sector organisation can apply for access, and once approved they get API credentials to send templated emails and SMS messages through the platform. The API itself is RESTful, token-authenticated, and documented openly at notifications.service.gov.uk. GDS publishes the backend code on GitHub too, which is useful for anyone who wants to understand what’s running under the bonnet.

    The architecture is fairly conventional. Client services authenticate with a bearer token (a JWT, specifically), POST to the /v2/notifications/email or /v2/notifications/sms endpoints with a template ID and the recipient’s address or mobile number, and Notify handles the actual delivery via third-party providers. Email goes through commercial transactional mail infrastructure; SMS goes through aggregators with UK carrier connections. The platform abstracts all of that away, which is the point.

    The sender ID trust model and why it matters

    Here’s where the GOV.UK Notify API setup gets genuinely interesting. For SMS, Notify lets organisations configure a custom alphanumeric sender ID. This is the name that appears at the top of your text message instead of a phone number. NHS trusts routinely configure these as “NHSRemind”, “YourNHS”, or similar. Councils use variants of their own names. HMRC uses “HMRC”.

    The problem is that alphanumeric sender IDs in the UK are managed by mobile network operators and their aggregator relationships. There is no central registry that makes “HMRC” an exclusive label that only HMRC can use. A bad actor with a bulk SMS aggregator account can send messages with the exact same sender ID. The message will land in the same conversation thread on an iPhone as a legitimate HMRC text, because iOS and Android group by sender name string. That’s not a Notify vulnerability. It’s a telecoms infrastructure problem that Notify’s output happens to make worse by normalising the expectation that these names mean something.

    For email, Notify enforces DKIM signing on outbound messages and requires sending domains to pass SPF and DMARC checks. That part of the stack is actually solid. Messages sent through Notify from a properly configured service will pass authentication checks. But that also means a phishing campaign that mimics a Notify-style email, using a typosquatted domain like “nhs-notifications.co.uk” with its own valid DKIM setup, looks almost identical to a real Notify email in any mail client that doesn’t surface raw headers. Anyone running email tester services on Notify output will see it score well precisely because the authentication infrastructure is properly configured.

    Terminal output showing GOV.UK Notify API JSON response data
    Photo by Bibek ghosh on Pexels

    Template trust and the social engineering surface

    Notify messages are template-driven. Each approved service builds templates inside the Notify dashboard, and those templates get a fixed ID. When the API call goes out, it references the template and injects personalisation fields. The templates themselves have a particular, recognisable house style: short, plain-language, action-oriented. “Your appointment is on 14 May. Reply YES to confirm or call 0300 xxx xxxx.” That format is now so embedded in UK public consciousness that spoofed messages using the same tone and structure bypass a lot of the mental alarm bells people should be ringing.

    The attack vector I’d flag here isn’t breaking into Notify itself. It’s simulating Notify’s output through independent channels. An attacker who understands how Notify messages are formatted, what sender IDs look plausible, and which services their targets are likely subscribed to (NHS, DWP, council tax) can build extraordinarily convincing lures. The social engineering payload is essentially the platform’s own design language, turned against recipients.

    This connects to a broader pattern I’ve written about before. The UK phishing domain infrastructure piece from earlier this year covers how cheap .co.uk registrations and fast-flux hosting let campaigns stand up convincing-looking service sites in under an hour. Combine that with a spoofed Notify-style SMS pointing to a fake “verify your appointment” landing page, and you’ve got a multi-stage attack chain that requires no Notify compromise at all.

    API security: what Notify gets right

    To be fair to GDS, the Notify API isn’t badly designed. JWT authentication with rotating service-specific API keys is sensible. Separate keys for test and production environments reduce the blast radius of a leaked key. The platform maintains delivery receipts and status tracking through callback URLs, which means consuming services can audit what was sent and when. Rate limiting is in place, though the specific thresholds aren’t publicly documented.

    The bigger risk on the API side is credential hygiene on the consuming service’s end. I’ve seen enough UK government and NHS repositories leaking secrets on GitHub to know that Notify API keys in committed config files are not a hypothetical. A leaked production key gives an attacker direct sending capability from a legitimate service identity, complete with that service’s configured sender ID. At that point you’re not spoofing anything; you’re just using the platform exactly as intended, but for someone else’s recipients.

    What consuming services should actually be doing

    Any public sector team integrating with the GOV.UK Notify API should treat the API key like a private signing key: never in version control, always injected through environment variables or a secrets manager, rotated on a schedule and immediately after any suspected exposure. The GDS documentation says this, but documentation doesn’t always survive contact with a rushed deployment.

    Beyond credential management, there’s a case for including message authenticity signals in the templates themselves. Something as simple as a unique reference number that recipients can verify on the originating service’s website creates a second check. It’s not cryptographic, but it raises the cost of a convincing fake.

    On the SMS sender ID front, the options are more limited because the problem lives at the telecoms layer rather than the application layer. Ofcom has consulted on SMS sender ID protection measures before, and the debate around a UK equivalent of a registered sender registry has been slow-moving. Until that changes, organisations using Notify for high-stakes notifications (benefits decisions, medical appointments) should consider whether SMS is the right channel at all for anything requiring a follow-on action from the recipient.

    The bigger picture: trusted infrastructure as an attack surface

    The GOV.UK Notify API is a good product solving a real problem. Centralising government messaging infrastructure reduces duplicated effort, improves deliverability, and makes it easier for small councils and NHS trusts to send professional communications without building their own transactional mail stack. That’s all genuinely useful.

    But trusted infrastructure attracts attackers because trust is exactly what they’re trying to steal. The more consistently Notify-style messages look and feel authoritative, the more valuable the template becomes for anyone trying to manufacture that same authority fraudulently. It’s the same dynamic that makes DVLA’s vehicle data lookup surface attractive: legitimate systems, widely relied upon, create known expectations that adversaries can exploit from the outside without ever touching the system’s own internals.

    My take is that GDS understands this tension, but the platform’s trust model has outpaced the defensive messaging around it. Most people in the UK have no mental model for how GOV.UK Notify works. They just see an official-looking text from “HMRC” and act on it. That gap between platform sophistication and public awareness is where the real risk lives, and no amount of JWT rotation fixes that.

  • How Smart Meters Are Talking to the National Grid: The SMETS2 Communication Stack, Vulnerabilities, and What Ofgem Isn’t Telling You

    How Smart Meters Are Talking to the National Grid: The SMETS2 Communication Stack, Vulnerabilities, and What Ofgem Isn’t Telling You

    Every 30 minutes, around 32 million smart meters across the UK silently transmit your energy consumption data across a layered communication stack that most people, and frankly, most journalists, have never looked at properly. I’ve spent some time pulling apart how this system actually works, and what I found is a genuinely interesting piece of national infrastructure with some architectural decisions that should make any security researcher raise an eyebrow. The SMETS2 smart meter architecture is more complex, more distributed, and in some ways more fragile than Ofgem’s public-facing messaging ever lets on.

    Close-up of a SMETS2 smart meter display showing the SMETS2 smart meter architecture communication unit
    Photo by Anh-Bao Tran-Le on Pexels

    What SMETS2 actually is (and why SMETS1 was a disaster)

    SMETS stands for Smart Metering Equipment Technical Specifications. The first generation, SMETS1, was an embarrassment. Meters were locked to individual energy suppliers, switch supplier and your smart meter reverted to a dumb one, sending you back to manual readings. Roughly 4 million SMETS1 meters had to be remotely upgraded or physically replaced. The core problem was that each supplier built proprietary comms stacks with no interoperability layer underneath.

    SMETS2 fixed that by routing everything through a central intermediary: the Data Communications Company, or DCC. The DCC is a licensed body regulated by Ofgem, and it runs the Wide Area Network (WAN) relay that sits between your meter and your supplier’s systems. Every command, whether it’s a firmware update, a tariff change, or a remote disconnection, has to pass through the DCC’s infrastructure. In theory, this creates accountability. In practice, it creates a single point of architectural trust that’s worth examining closely.

    The three-layer comms stack: HAN, WAN, and DCC relay

    The SMETS2 communication stack has three distinct layers, and understanding each one is essential before you can reason about its attack surface.

    The Home Area Network (HAN) is the local mesh between your smart meter, your In-Home Display (IHD), and any Consumer Access Devices (CADs) you’ve authorised. It runs on Zigbee, specifically Zigbee Smart Energy Profile 1.x (SEP 1.x), operating at 2.4GHz. The HAN uses AES-128 encryption with pre-provisioned keys baked into devices during manufacture. The Zigbee coordinator role sits in the Communications Hub, which is a separate module physically attached to or integrated with the meter itself. Range is typically 10-15 metres through walls, so in a terraced house, your neighbour’s HAN and yours can physically overlap in signal space, even if they can’t join each other’s network without the right keys.

    The Wide Area Network (WAN) is the cellular uplink. SMETS2 meters use GPRS (2G) as the baseline, with some deployments using 3G or LTE depending on the Communications Hub variant. The WAN carries traffic between the Communications Hub and the DCC’s network. The WAN uses a separate security layer on top of the cellular transport, specifically DLMS/COSEM (Device Language Message Specification / Companion Specification for Energy Metering) with elliptic-curve cryptography for authentication and TLS for transport. The metering protocol itself is IEC 62056 compliant.

    The DCC relay layer is where it gets interesting. The DCC doesn’t just passively route messages, it enforces a role-based access model. Every party that wants to send a command to a meter (your supplier, a network operator, a third-party service provider) has to authenticate with the DCC’s Remote Party Message Broker and have the correct authorisation level for that command type. Command types are categorised: read-only commands, critical commands (like remote disconnection), and firmware updates sit in different security tiers. The DCC also logs every transaction, which creates a fairly comprehensive audit trail, though I’ll come back to what that audit trail actually covers in a moment.

    Dark server rack and cables representing the DCC relay infrastructure in the SMETS2 smart meter architecture
    Photo by Brett Sayles on Pexels

    Known protocol weaknesses worth actually worrying about

    Let me be clear: the SMETS2 stack is meaningfully more secure than SMETS1 and than many comparable deployments in other countries. But “more secure” doesn’t mean “without issues.”

    The HAN’s reliance on Zigbee SEP 1.x is the most obvious concern. Zigbee SEP 2.0 exists and uses TLS 1.2 over TCP/IP, which is substantially more robust. The decision to stay on SEP 1.x was largely a commercial and backwards-compatibility decision made years ago when the rollout began. Researchers at Lancaster University published work in 2020 demonstrating traffic analysis attacks against Zigbee SEP deployments, not breaking the encryption, but inferring occupancy and appliance usage from packet timing and size. Your HAN is leaking behavioural metadata even when the payload is encrypted.

    The WAN’s dependence on 2G GPRS is a more pressing concern in 2026, given that most UK operators have either switched off or are in the process of switching off their 2G networks. EE completed its 2G shutdown in 2024. Vodafone and Three are in progress. Ofgem and DESNZ have been managing a rolling Communications Hub replacement programme, but it’s slow. There are still tens of thousands of meters on GPRS connections that are increasingly operating on legacy spectrum kept alive specifically for IoT devices, a narrower, less resilient band that’s also more predictable for anyone doing signal intelligence work in the area.

    At the DCC relay layer, the audit trail I mentioned covers command transactions but does not independently verify the integrity of the consumption data the meter itself reports. The meter’s tamper detection is physical and firmware-based. A sophisticated attacker with physical access to the meter, a rented property is the obvious scenario here, and enough knowledge of the firmware could theoretically manipulate readings before they’re signed and transmitted. This isn’t a theoretical edge case: researchers at Eurecom demonstrated analogous attacks against smart metering infrastructure at the IEEE S&P symposium in 2023. The DCC’s logs would show a meter reporting, but not necessarily that the reported values were authentic.

    What a targeted attack on household energy telemetry would actually look like

    I want to be specific here, because vague threat modelling is useless. A realistic targeted attack isn’t someone cracking AES-128 from a van parked outside your house. It looks more like this:

    A malicious Communications Hub firmware update pushed through the DCC’s update mechanism, if an attacker compromised a DCC-authorised third party’s credentials and had sufficient access tier, they could potentially push a rogue firmware package to a subset of meters. The DCC does code-sign firmware, but the security of that signing infrastructure is itself a supply chain concern that isn’t publicly documented in any meaningful detail. For context, you can look at how UK public repositories have leaked credentials and API keys across government systems, the assumption that signing infrastructure is hardened everywhere isn’t one I’d make by default.

    More practically, a rogue CAD on the HAN is a lower-effort attack. Consumer Access Devices are authorised via the HAN joining process, and while that process requires a PIN, social engineering a householder into adding a device is trivial. Once a CAD is on the HAN, it can read meter data in near-real-time. Occupancy inference from energy telemetry is accurate enough to be useful for burglars, stalkers, or corporate competitors in commercial premises.

    Landlords navigating the energy compliance ecosystem face this from multiple directions. They’re dealing simultaneously with smart meter obligations, mandatory EPC assessments, and a tenant population that may have already authorised third-party CADs. Getting a Landlord EPC certificate is straightforward enough, but the broader smart metering compliance picture is something most letting agents have zero technical understanding of. The EU Cyber Resilience Act’s obligations for UK vendors are going to start touching smart home device manufacturers imminently, which will eventually push better HAN device standards, but that’s 2027 at the earliest.

    Data retention and what Ofgem’s guidance actually says

    Under the Smart Meters (Licensable Activity) Regulations 2016, the DCC is required to retain smart meter data for defined periods, but the specifics depend on what type of data and who’s requesting it. Half-hourly consumption data held by suppliers is typically retained for 24 months for billing purposes. The DCC’s own transaction logs have different retention windows. What Ofgem’s consumer-facing documentation doesn’t spell out clearly is that third-party service providers you’ve authorised, an energy monitoring app, a smart home platform, may retain your granular consumption data under their own privacy policies, for much longer, and with significantly weaker security obligations than the DCC itself imposes on licensed parties.

    I’d also point to the comparison with how personal data flows from UK public registers into commercial broker pipelines, smart meter data is potentially even more granular and valuable, and the third-party authorisation ecosystem around CADs creates exactly the same kind of downstream leakage problem.

    What you can actually do

    Audit your CAD authorisations. Most IHDs have a menu that shows authorised devices on your HAN. If you see something you don’t recognise, contact your supplier to revoke it. Be very reluctant to authorise any third-party energy app unless you’ve actually read their data retention terms.

    If you’re a landlord or a tenant in a property with a meter in an accessible common area, understand that physical access to that meter means physical access to the Communications Hub. Lock it properly. And if you’re renting out a property, know that your smart meter’s half-hourly data can infer your tenant’s behaviour at quite a fine grain, that’s data protection territory that most landlords haven’t thought about once.

    The SMETS2 architecture is genuinely well-designed in its core cryptographic assumptions. The weaknesses are at the edges: legacy 2G WAN links, the Zigbee HAN’s metadata leakage, third-party CAD authorisation creep, and an audit trail that verifies transactions but not data integrity. None of that is going to be fixed by Ofgem telling you your smart meter is “safe.” Know the stack. Know what it’s actually doing.

    Frequently Asked Questions

    How does a SMETS2 smart meter actually communicate with my energy supplier?

    Your SMETS2 meter sends data through a Communications Hub that connects to the Data Communications Company (DCC) via a cellular WAN link, typically GPRS or LTE. The DCC then relays commands and data between the meter and your supplier’s systems. Neither your supplier nor any third party can communicate directly with your meter without going through the DCC’s authentication and authorisation layer.

    Can my SMETS2 smart meter be hacked remotely?

    Directly cracking the cryptography is highly unlikely for a typical attacker. The realistic risks are at the edges: compromised third-party credentials giving DCC access, rogue Consumer Access Devices added to your Home Area Network, or traffic analysis revealing occupancy patterns from your HAN’s Zigbee traffic. Remote disconnection commands do exist in the SMETS2 command set and require DCC-tier authorisation, but the security of who holds those authorisations is worth scrutinising.

    What is the DCC and why does it matter for smart meter security?

    The Data Communications Company is the Ofgem-licensed body that acts as the central relay for all SMETS2 meter communications in Great Britain. Every command sent to your meter, from a tariff update to a firmware push, must pass through the DCC’s infrastructure and be authenticated against its role-based access model. This creates a single architectural trust point, meaning its own security posture matters enormously for the entire national smart metering estate.

    How long is my smart meter consumption data kept, and who can see it?

    Suppliers typically retain half-hourly consumption data for 24 months under billing regulations. However, any third-party apps or Consumer Access Devices you’ve authorised on your Home Area Network may retain your data under their own, often less stringent, privacy policies and for longer periods. The DCC maintains transaction audit logs separately. Checking and revoking unnecessary third-party authorisations is worth doing via your IHD menu or supplier account.

    Is the Zigbee protocol used in smart meters secure?

    SMETS2 uses Zigbee Smart Energy Profile 1.x with AES-128 encryption, which provides reasonable payload security. The known weakness is metadata leakage, researchers have shown that packet timing and size can reveal occupancy and appliance usage patterns even without decrypting the payload. Zigbee SEP 2.0 (which uses TLS over TCP/IP) would be more robust, but the SMETS2 rollout committed to SEP 1.x for compatibility reasons and changing that now would require widespread Communications Hub replacements.

  • Dissecting UK Phishing Infrastructure in 2026: How Cybercrime Groups Register, Host, and Burn Domains Inside .uk and .co.uk Namespaces

    Dissecting UK Phishing Infrastructure in 2026: How Cybercrime Groups Register, Host, and Burn Domains Inside .uk and .co.uk Namespaces

    Phishing isn’t new. But the machinery behind it has got considerably more sophisticated, and nowhere is that clearer than in campaigns targeting UK brands. I’ve spent time pulling apart the patterns behind lures impersonating Lloyds Bank, HMRC, and Royal Mail, and what you find underneath is a genuinely professional operation: deliberate Nominet registration abuse, layered hosting, and DNS tricks that make attribution a nightmare. This is a breakdown of how UK phishing domain infrastructure in 2026 actually works, from the moment a domain gets registered to the moment it gets burned and replaced.

    Anonymous hacker at dark terminal screens representing UK phishing domain infrastructure 2026
    Photo by Rafael Minguet Delgado on Pexels

    How attackers register convincing .uk and .co.uk domains

    The .co.uk namespace is a gift to phishers. Nominet’s registration system, accessed through accredited registrars, requires no real identity verification for the registrant beyond what the registrar chooses to collect. Privacy proxy services, reseller accounts under lax KYC registrars, and prepaid card payments all combine to make the initial registration almost untraceable. The attacker’s goal is to get a domain that looks authoritative on a mobile screen where the full URL is already truncated.

    Typical patterns I’ve observed across campaigns include homograph-adjacent tricks: lloyds-secure-login.co.uk, hmrc-refund-portal.uk, royalmail-redelivery-gb.co.uk. The .uk second-level domain (rather than .co.uk) has become increasingly popular because it looks shorter and slightly more official. Nominet actually publishes guidance on suspicious registrations, but the volume is too high for manual review to catch most of them before they go live. Registrations often cluster in batches, a single actor might register 15-20 similar domains in one session, cycling through registrar accounts to stay under velocity checks.

    One pattern that’s become very common is typosquatting combined with keyword stuffing: inserting words like “secure”, “verify”, “update”, “gb”, or “official” into the domain string. These pass automated plausibility checks because they don’t exactly match the brand’s registered trademark. Nominet’s Rapid Response Service can suspend domains within 24 hours once reported, but that window is usually long enough for a campaign wave to run its course.

    Bulletproof hosting and why it’s still working

    Once a domain is registered, it needs infrastructure that won’t fold the moment someone files an abuse complaint. That’s where bulletproof hosting (BPH) comes in. The term is slightly misleading, no host is literally immune to takedowns, but BPH providers are structured to maximise the time an operation stays live. They’re typically registered in jurisdictions with slow or non-existent response to foreign abuse reports, and they often front through legitimate-looking resellers or sub-allocations of IP space from larger providers.

    In UK-targeted campaigns, I’ve seen phishing pages hosted across a mix of Eastern European ASNs, offshore VPS providers, and occasionally inside major cloud providers via compromised trial accounts. AWS and Azure trial accounts, spun up with stolen card details, give attackers access to IP ranges that many corporate firewall blocklists explicitly trust. A Royal Mail phishing page sitting on an AWS IP with a valid TLS certificate and a .co.uk domain is going to slip past a lot of filters.

    Fast-flux DNS: the trick that keeps phishing pages alive

    Fast-flux DNS is the technique that makes takedowns genuinely painful. Rather than pointing a domain at a single server, a fast-flux setup rotates through dozens or hundreds of IP addresses, each with a very low TTL (often 60 seconds or less). A takedown request that successfully nullroutes one IP is irrelevant; by the time it’s processed, the DNS has already moved on. Some operations run double-flux, rotating not just the A records but the nameservers themselves.

    The actual phishing content typically lives on a stable backend server, while the rotating IPs are just proxies or compromised residential machines (often recruited via malware botnets). From the victim’s perspective, the page loads normally. From a takedown team’s perspective, there’s no single throat to choke. UK ISPs operating under the IWF’s blocking infrastructure can push URL-level blocks, but fast-flux makes IP-level blocking nearly useless.

    The NCSC’s Early Warning service flags some of this, if you’re curious how far that visibility actually extends, my breakdown of how the UK’s threat intel platform works and where it goes blind is worth a read alongside this. Spoiler: fast-flux infrastructure in particular is a known gap.

    Certificate transparency log abuse: how phishers use CT logs as a launch pad

    Here’s one that doesn’t get talked about enough. Certificate Transparency (CT) logs, specifically services like crt.sh, are public databases of every TLS certificate issued. They exist to make the web more trustworthy. Phishers have flipped that around.

    When a security researcher or brand protection team registers a new domain to monitor, that registration shows up in CT logs almost immediately. Phishers run automated watchers on CT logs looking for newly issued certificates tied to brand keywords. Spot lloyds or hmrc in a new cert? Clone the target’s legitimate page, spin up infrastructure under your own similar-looking domain, and race to get your campaign live before the legitimate cert owner’s page is even indexed. It’s adversarial intelligence gathering from public infrastructure.

    The same technique works in reverse for defenders, monitoring CT logs for your own brand strings is a reasonable early-warning tripwire. But it requires dedicated tooling and someone awake to action the alerts.

    The HMRC lure playbook and why it works so well

    HMRC lures are perennially effective because they exploit a real emotional trigger: money owed or refunds due. I’ve looked at dozens of these campaigns and the template is remarkably consistent. The landing page mimics the GOV.UK design system almost pixel-perfectly, right down to the crown logo and the specific font stack. The form collects National Insurance number, date of birth, and bank details in sequence, each step looking entirely plausible because government forms genuinely do ask for all of these in roughly this order.

    What’s interesting from an infrastructure angle is that HMRC lures tend to use domains registered well in advance of campaign launch, sometimes weeks ahead. The domain sits parked or serves a generic holding page while the attacker waits for an optimal send window (typically the week after a tax deadline, when people are anxious about their returns). This parking behaviour means the domain passes initial reputation checks that blocklists run against newly registered domains. By the time the phishing page goes live, the domain is days or weeks old and looks seasoned.

    This connects to a broader pattern of data abuse I’ve covered before: if you want to understand how personal data ends up in targeting lists that make these lures so precise, how UK electoral roll data flows into commercial data broker pipelines explains exactly how attackers get the seeds for their victim lists.

    The burn cycle: how fast domains get discarded

    The lifecycle of an active UK phishing domain is short. My reading of campaign patterns suggests most domains are considered spent within 48 to 72 hours of the main send wave. Blocklists and automated scanners catch them, abuse reports hit the registrar, and the phishing kit moves to the next pre-registered domain in the queue. The attacker has already registered the replacements. This is why bulk domain registration is so central to modern phishing operations, it’s not one domain, it’s a magazine of them.

    The actual phishing kits themselves often get reused across multiple domains, which is useful for attribution. Kit fingerprinting, identifying shared code, identical file structures, specific encoding patterns, is one of the more reliable ways threat intel teams track a single actor across dozens of burned domains. Palo Alto’s Unit 42 and the NCSC both publish periodic reports on kit fingerprints tied to UK-targeting campaigns, and the consistency is often striking.

    For defenders specifically: if your organisation’s brand is a regular lure target, monitoring Nominet’s WHOIS data for keyword registration patterns, subscribing to CT log alerting, and feeding your SIEM with takedown velocity data will give you a much clearer picture than waiting for user reports. And if you run your own hosted infrastructure, the risk of it being cloned for credential harvesting is real, particularly if you’ve ever accidentally pushed config data publicly, which is more common across UK organisations than anyone wants to admit.

    The infrastructure behind UK phishing campaigns isn’t improvised. It’s methodical, operationally aware, and specifically tuned to outlast standard takedown timelines. Understanding each layer of it is the only way to push back effectively.

    Frequently Asked Questions

    How do phishing domains targeting UK brands get registered so quickly?

    Most are registered through accredited Nominet registrars using privacy proxy services and minimal KYC. Attackers often pre-register batches of domains days or weeks before a campaign launches, so they’re ready to swap in the moment one gets blocked or reported.

    What is fast-flux DNS and why does it make phishing so hard to take down?

    Fast-flux DNS rotates the IP addresses attached to a domain every 60 seconds or less, so blocking a single server doesn’t kill the phishing page. The actual content lives on a stable backend, while the rotating IPs, often compromised home machines, act as disposable proxies.

    How are certificate transparency logs being abused by phishing groups?

    Phishers run automated watchers on public CT log services like crt.sh, looking for newly issued certificates tied to brand keywords. When a target’s new cert appears, attackers clone the page and race to launch a campaign under a similar-looking domain before the legitimate site is even indexed widely.

    Why are HMRC and Royal Mail phishing lures so convincing?

    Both use publicly familiar design systems, GOV.UK’s layout for HMRC, and Royal Mail’s standard parcel notification templates, that victims have genuinely seen before. The forms ask for data in the same sequence real services do, which makes each step feel routine rather than suspicious.

  • Git Secrets in the Wild: How UK Government and NHS Public Repositories Are Still Leaking API Keys, Credentials, and Internal Hostnames

    Git Secrets in the Wild: How UK Government and NHS Public Repositories Are Still Leaking API Keys, Credentials, and Internal Hostnames

    Every week, somewhere in the UK public sector, a developer pushes a commit to a public GitHub or GitLab repository and accidentally ships a secret with it. An API key tucked inside a config file. A hardcoded database password that got copied from a local .env and never stripped out. An internal hostname that maps directly to a server sitting behind a government firewall. This is the UK government GitHub secrets leak problem, and despite years of tooling advances, it is nowhere near solved.

    I’ve spent time crawling public repos tied to NHS trusts, local councils, and contractors who work the HMRC supply chain. What I found is not a tale of one rogue developer making a stupid mistake. It is a structural failure baked into how the public sector approaches open-source contribution and developer workflow governance.

    Security researcher examining UK government GitHub secrets leak in terminal output at night
    Photo by Rafael Minguet Delgado on Pexels

    Where the secrets are actually hiding

    The obvious place to look is the current HEAD of a repository. Scan the live files, grep for AKIA (AWS access key prefix), look for ghp_ (GitHub personal access tokens), search for private key headers. Tools like TruffleHog do this automatically and surface hits within seconds. But the more interesting, and more persistent, problem lives in commit history.

    Git is a version control system. Its entire point is remembering everything. When a developer realises they’ve committed a secret and deletes it in a follow-up commit, the secret does not disappear. It sits in every prior commit object. If the repository is public, anyone who clones it gets the full history. A secret deleted three years ago is still retrievable with a single git log -p piped through a grep. This is not an edge case. It is how Git works.

    The pattern I see most frequently in UK public sector repos is something like this: an NHS digital team open-sources an integration project, strips the obvious secrets from the current codebase, marks the repo public, and considers the job done. The commit history, however, contains six months of development where API tokens for NHS login services, SMTP credentials for patient notification systems, and internal hostname references were present in plain text.

    The methodology for responsible discovery

    Before going further, let’s be clear about scope. Finding these secrets is not the same as exploiting them. Responsible security research means documenting what you find, assessing whether a secret is still live and rotatable, and reporting it to the relevant organisation before publishing anything. The NCSC’s coordinated vulnerability disclosure guidance (available at ncsc.gov.uk) covers exactly this territory, and I’d strongly encourage anyone doing this kind of research to read it first.

    That said, here is a practical methodology for auditing public repositories tied to UK public sector organisations. Start with GitHub’s search syntax. Queries like org:nhsengland filename:.env or org:hmrc password surface results fast. GitLab has equivalent search capabilities on public projects. You can also use Gitrob or TruffleHog pointed at an organisation’s public repos to automate the sweep across commit history, not just current files.

    Once you have hits, triage them. Not all secrets are equal. An expired OAuth token is annoying but harmless. A live AWS key with IAM permissions attached to a government contractor’s account is a different matter entirely. For anything that looks live, test carefully and minimally. A HEAD request to an internal API endpoint to confirm it resolves is very different from actually authenticating and reading data. Document everything with timestamps, repo URLs, and commit hashes.

    Report to the organisation’s security contact or, if you can’t find one, via the NCSC’s reporting mechanism. Give them a reasonable deadline, typically 30 days, before any public disclosure. Most public sector teams, in my experience, are genuinely grateful when you flag this stuff properly. They just had no idea the exposure existed.

    Why commit-history scrubbing keeps failing

    The technically correct fix for a secret in commit history is a full rewrite of that history using tools like git filter-repo (the modern replacement for the deprecated BFG Repo Cleaner, though BFG still works fine for this specific job). This removes the secret from every commit object, produces a new commit graph, and requires a force push to the remote. Every collaborator then needs to re-clone or rebase onto the rewritten history.

    That last part is where it falls apart in large organisations. A council IT department running a shared GitHub organisation might have dozens of forks, CI/CD pipelines cloning specific commit SHAs, and third-party contractors who have already cloned the repo. Rewriting history breaks all of those references. In practice, teams patch the current file, commit a deletion, and move on. The secret stays in the history because actually cleaning it up is disruptive and the team lead decides the risk is acceptable, usually without fully understanding that the history is still public.

    There is also a caching problem. GitHub and GitLab cache repository data aggressively. Even if you perform a correct history rewrite and force-push, the old commit objects remain accessible via direct hash references for a period while the platform’s garbage collection catches up. And if anyone ran git clone before you cleaned the history, they have a local copy you cannot touch.

    The real fix is never committing secrets in the first place. Pre-commit hooks running tools like detect-secrets or gitleaks catch them before they ever reach the remote. GitHub’s own push protection feature, available on public repositories, flags known secret patterns at push time. These tools exist. The public sector is simply not mandating their use systematically.

    The structural problem behind the pattern

    This connects to a broader issue I’ve written about before with UK public sector data exposure. The same culture that allows Companies House data to be weaponised for corporate identity fraud and permits DVLA lookup surfaces to be systematically scraped is present in how government development teams treat open-source repositories. Security is an afterthought bolted on after something goes wrong, not a default built into the workflow from the start.

    The Cabinet Office’s Technology Code of Practice says government services should use open standards and make source code open by default where possible. That is a genuinely good principle. The problem is that “open by default” requires “secure by default” to accompany it, and the guidance on secrets management in that code is vague enough that individual teams interpret it however they like.

    Contractors are a particular weak point. HMRC, for instance, uses a large ecosystem of technology vendors who build and maintain systems under contract. Those contractors sometimes maintain their own public repos as part of their wider business. Internal hostnames, staging environment credentials, and integration API keys from government systems turn up in contractor repos that have nothing on their face to suggest a government connection. The attack surface is distributed across dozens of organisations, and no single team owns visibility of all of it.

    The approach taken with the NCSC’s Early Warning service shows that centralised threat monitoring infrastructure does exist in the UK, but passive monitoring of known infrastructure is very different from proactively scanning public repositories for credential exposure. That gap is where the UK government GitHub secrets leak problem lives, mostly unexamined, definitely unresolved.

    What actually works

    Mandate pre-commit hooks as a condition of contributing to any public-sector repository. This is not complicated to implement. A shared .pre-commit-config.yaml in every organisation’s template repository, with gitleaks as a required hook, would catch the majority of accidental commits before they happen. Pair that with GitHub push protection enabled at the organisation level, and you cut the exposure surface dramatically.

    Rotate secrets on a schedule regardless of whether you think they’ve been exposed. If a key has been alive for more than 90 days in a repo with any public history, rotate it. The cost is low. The cost of leaving a live key in a historical commit that someone discovers at 2 AM on a Sunday is considerably higher.

    Run regular automated scans against your own organisation’s public repos using TruffleHog or Gitleaks in CI. Treat findings as P1 incidents. And if you are a contractor building systems for government, scope your secret management practices to meet at least the same standard as the client organisation’s security policy requires, because right now many of them simply do not.

    The tooling to solve this problem has existed for years. The will to enforce it systematically across the public sector is what’s missing.

  • 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.

The Latest