Category: Tech News

  • Dissecting the UK’s National ANPR Network: How Plate Reads Flow, Who Can Query Them, and What the Retention Logs Show

    Dissecting the UK’s National ANPR Network: How Plate Reads Flow, Who Can Query Them, and What the Retention Logs Show

    There are more than 11,000 ANPR cameras operating across the UK right now, reading number plates, timestamping them, and firing that data into a centralised police database. Every motorway gantry, most A-road junctions, and a growing number of council-run sites are feeding a system that logs your movements whether you’re a suspect or not. I’ve spent a fair amount of time reading the College of Policing’s code of practice and the associated data audit trails, and what’s in there is genuinely worth unpacking for anyone who cares about surveillance architecture.

    UK national ANPR network camera on motorway gantry at dusk capturing plate reads
    Photo by Al Rashed on Pexels

    The system is called the National ANPR Data Centre (NADC), and it sits under the NPCC (National Police Chiefs’ Council) rather than any single force. The technical read pipeline is straightforward in principle: a camera captures a plate, optical character recognition resolves it to a string, and the read (plate number, timestamp, GPS coordinates, camera ID, direction of travel, and a JPEG of the vehicle) gets pushed over an encrypted connection to a regional aggregation node, which forwards to the national store. The whole journey from shutter to searchable record takes roughly two to three seconds. At scale, the NADC processes somewhere north of 60 million reads per day. That’s not speculation, NPCC has stated figures in that range in parliamentary submissions.

    Who actually has access to ANPR query rights?

    The access model is tiered. Every UK police force gets read access, obviously. But the list goes further than most people realise. The National Crime Agency, Border Force, HMRC’s fraud and serious crime teams, the Driver and Vehicle Licensing Agency for specific enforcement purposes, and certain military police units all hold approved query rights under the current framework. Intelligence agencies can access the data under the Intelligence Services Act, though the precise mechanics of that pathway aren’t documented publicly in any granular way.

    At the operational level, a PC on patrol can run a plate through the Police National Computer and get an ANPR hit response without touching the NADC directly. Detectives investigating serious crime submit retrospective queries, “show me every read of this plate in the last 90 days”, through a structured request process that’s supposed to be logged and audited. The audit trail is real, but the oversight is patchy. The Surveillance Camera Commissioner’s office has noted repeatedly that self-auditing by forces is inconsistent, and there’s no independent real-time monitoring of query patterns.

    How ANPR retention periods actually work

    Under the College of Policing’s ANPR code of practice, standard retention is two years for reads that don’t match a vehicle of interest, and indefinite retention where the read is linked to a crime record. The two-year baseline sounds reasonable until you think about what it means in practice: your full movement history, every motorway service station, every town centre, every late-night drive, sits queryable for 730 days by anyone with the right credentials and a plausible operational reason.

    Dark server rack representing the UK national ANPR network centralised database infrastructure
    Photo by panumas nikhomkhai on Pexels

    The “vehicle of interest” flag is where it gets complicated. A plate can be flagged against the Police National Computer for unpaid insurance, an expired MOT, or a simple keying error in a legacy database. Once flagged, reads don’t age out under the standard two-year window. I’ve read cases where vehicles were cleared of any offence but remained flagged in PNC for months, meaning ANPR reads continued accumulating on an extended retention schedule without the owner ever knowing. The ICO has received complaints about this, though enforcement action against specific forces remains rare.

    There’s also the question of what “deletion” actually means. Marked-for-deletion records in large distributed systems frequently persist in backup stores, cold storage, and analytic extract databases long after the headline retention window expires. The NADC’s data governance documentation doesn’t address this in any detail the public can access. The Home Office’s responses to Freedom of Information requests on backup purge cycles have been consistently refused under section 31 (law enforcement). Draw your own conclusions.

    The civil liberties attack surface

    The legal basis for bulk ANPR collection is the Police Act 1997 combined with the Investigatory Powers Act 2016, with RIPA-era precedents still baked into how forces justify retrospective queries. The problem is that neither statute was written with mass passive surveillance of innocent people in mind. Every single vehicle that passes an ANPR camera gets logged, there’s no threshold, no reasonable suspicion requirement for the initial capture. This is fundamentally different from a targeted intercept and the legal framework hasn’t quite caught up with what the technology actually does.

    Civil liberties groups including Liberty and Big Brother Watch have been arguing this point for years. The European Court of Human Rights has found against blanket surveillance schemes in analogous contexts, but ANPR sits in a legal grey area because each individual read is framed as trivial. One plate read, by itself, reveals almost nothing. Two years of reads on a single vehicle reveals your GP, your lawyer, your political meetings, your religious practice, and your relationships. The aggregation is the problem, and current law treats it as if it were the same as a single read.

    This aggregation risk is directly comparable to what we’ve covered before with electoral roll data flowing into commercial broker pipelines, individually mundane data points becoming a surveillance profile once they’re combined and queried at scale. The difference with ANPR is that the state is doing the aggregating directly, rather than outsourcing it to data brokers.

    Scope creep and third-party access

    Here’s where it gets thornier. Local councils now operate significant numbers of ANPR cameras for clean air zone enforcement and parking management. Some of these feeds are integrated into police networks under data sharing agreements; others sit in separate silos but are accessible under section 22 data requests. The boundary between council ANPR for traffic management and police ANPR for surveillance is genuinely blurry at the infrastructure level, and the public-facing transparency about which feeds go where is minimal.

    Insurance companies had partial access to ANPR data through the Motor Insurers’ Bureau for enforcement purposes, though the scope of that arrangement has been challenged. Private car park operators running their own ANPR systems sit entirely outside the College of Policing code but can be compelled to hand over footage under a production order. This fragmentation means there’s no single body with a complete picture of how ANPR data flows across public and private systems in the UK.

    The comparison with how smart meter communication data gets handled by the DCC is useful here. Both systems collect granular behavioural data on the general population, both have retention frameworks that were written before the full surveillance implications were understood, and both rely heavily on self-auditing by the organisations that benefit from the data. The oversight model in both cases is structurally insufficient for the scale of intrusion involved.

    For those building threat models around personal privacy, the honest answer is that short of avoiding motorway and A-road travel entirely, there’s no practical way to opt out of ANPR capture. Obfuscation techniques like altered plates are criminal offences under the Road Vehicles (Display of Registration Marks) Regulations 2001. The DVLA and police take a dim view of attempts to defeat ANPR, for obvious enforcement reasons. Your best lever is the right of subject access under UK GDPR, which theoretically entitles you to request what reads exist against your plate, though forces have been slow to build processes that make this practically usable. The ICO is the relevant regulator if forces ignore or stonewall a subject access request, though as with many civil liberties issues, the remedies are slow and the deterrent effect on bad practice is limited.

    If you’re running any kind of operational security assessment for clients, the ANPR data trail is worth factoring into movement analysis. Tools that aggregate public and semi-public data have become increasingly capable; platforms like Nusan are part of a broader ecosystem where data visibility across multiple sources is becoming the norm for investigators and analysts alike. The same aggregation capability that makes these tools useful for legitimate research is exactly why the NADC’s query access controls need far more scrutiny than they currently get.

    The UK’s ANPR network is impressive infrastructure, technically speaking. It’s also one of the most extensive passive surveillance systems operating on a civilian population anywhere in the world, running largely below public awareness with oversight mechanisms that haven’t scaled to match its reach. That gap is the real attack surface. Not the cameras themselves, but the institutional complacency about what two years of bulk movement data actually represents.

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

  • How UK Emergency Services Are Patching Comms Gaps With Mesh Networking and LoRa: The DIY Infrastructure Filling Whitehall’s Blind Spots

    How UK Emergency Services Are Patching Comms Gaps With Mesh Networking and LoRa: The DIY Infrastructure Filling Whitehall’s Blind Spots

    There is a version of this story that Whitehall would prefer you never read. Somewhere in a Welsh valley, or on the edge of a Scottish moorland, a volunteer with a soldering iron and a Raspberry Pi is doing the job that a multi-billion-pound government infrastructure programme was supposed to do. The Emergency Services Network has been delayed so many times that it has become something of a dark joke in technical circles. Airwave, the existing TETRA-based system, still has coverage holes that could swallow a rescue team whole. And in those gaps, something genuinely interesting is happening: volunteer-run technical communities are building their own comms infrastructure, piece by piece, node by node.

    I have spent time talking to the people doing this work, and what strikes me most is not the ingenuity, though there is plenty of that. It is the sheer necessity of it. This is not hobbyist radio enthusiasm for its own sake. This is LoRaWAN emergency communications UK that exists because the official answer is still years away, if it arrives at all.

    LoRaWAN gateway antenna on a rural UK hilltop compensating for emergency communications coverage gaps
    Photo by Barnabas Davoti on Pexels

    The Airwave and ESN problem, in plain terms

    Airwave is a TETRA-based digital radio network run by Motorola Solutions under contract to the Home Office. It costs around £550 million a year to run and was supposed to be replaced by the Emergency Services Network, which was meant to use commercial 4G LTE infrastructure managed by EE. ESN has been in various states of crisis since at least 2016. The National Audit Office has flagged it repeatedly, most recently noting that the programme has cost over £11 billion when sunk costs are included, with full operational capability still not delivered.

    The practical problem in rural areas is coverage. Commercial 4G infrastructure, which ESN depends on, follows commercial logic. It goes where the subscribers are. Dartmoor, the Brecon Beacons, Sutherland, the North York Moors. These places have sparse coverage at best and genuine blackspots at worst. Retained fire crews responding to a wildfire, mountain rescue teams on a callout, ambulance crews navigating a moorland track: all of them can find themselves without a reliable radio link at the exact moment they need one most. For context on what this kind of systemic neglect does to rural emergency capability more broadly, this piece on the quiet crisis in britain’s volunteer fire services: how rural communities are being left to burn is worth reading alongside what follows.

    What LoRa actually is, and why it fits this problem

    LoRa stands for Long Range. It is a physical layer modulation technique developed by Semtech, and it is genuinely clever. By using chirp spread spectrum modulation across narrow bandwidths, LoRa achieves remarkable range on very low power. A single node running on a small battery can push a packet 10 to 15 kilometres across open terrain. In hilly country that number drops, but the technology tolerates adverse RF environments better than most alternatives at this price point.

    LoRaWAN is the network protocol that sits on top of LoRa, defining how devices authenticate, how packets are routed, and how gateways connect to a network server. The Things Network, which has community-run gateways across the UK, operates on LoRaWAN. So does Helium, though its coverage in rural Britain is spottier than the marketing implies. The key point is that a LoRaWAN gateway costs between £80 and £300 depending on specification, runs on mains or solar, and can be mounted on a fence post. You do not need a planning application for a small antenna installation below certain height thresholds, and Ofcom licences the 868 MHz band used by LoRaWAN in the UK as licence-exempt, meaning communities can deploy without spectrum fees.

    LoRa radio module used in UK volunteer emergency communications mesh networking deployments
    Photo by Arturo A on Pexels

    How volunteers are actually deploying this

    The implementations I have seen or heard described vary quite a bit in sophistication. At the simpler end, local amateur radio clubs are placing Dragino LPS8N or RAK7268 gateways on hill farms and community buildings, stitching together coverage along valleys where Airwave drops out. The nodes feed into a self-hosted ChirpStack network server, which logs telemetry and can relay alerts via MQTT to a web dashboard that duty controllers can watch. The data rate on LoRaWAN is low, between 250 bits per second and about 11 kilobits per second depending on spreading factor, so you are not streaming audio. What you can do is send GPS coordinates, status codes, and short text alerts reliably across distances that would defeat a standard UHF handheld.

    More ambitious deployments are using Meshtastic, an open-source mesh protocol that also runs on LoRa hardware, typically the LILYGO T-Beam or Heltec LoRa 32 boards. Meshtastic builds a peer-to-peer mesh where every node acts as a repeater. There is no central gateway dependency, which matters enormously in an emergency scenario where infrastructure can fail. A team of four people on a hillside, each carrying a T-Beam, forms its own self-healing mesh. Add a node on the summit and you extend range down into the valley where the incident commander is parked. The whole setup costs less than £200 in hardware and runs on 18650 lithium cells.

    Some groups are going further, integrating LoRa sensor nodes with existing digital modes used in amateur radio, particularly the APRS (Automatic Packet Reporting System) network. APRS has been used by mountain rescue teams in the UK for years and has a mature UK gateway infrastructure. Bridging LoRa mesh nodes into APRS gives you a hybrid system with significantly wider reach. It is, to be direct about it, a patchwork. But it is a functional patchwork, which is more than can be said for ESN in certain grid squares.

    The governance vacuum nobody wants to talk about

    Here is where it gets uncomfortable. Volunteer-deployed infrastructure operating in emergency support roles sits in a genuinely grey legal and operational space. These systems are not accredited by NPCC, not integrated into control room CAD systems, and not subject to any formal resilience testing. If a Meshtastic node gives a mountain rescue team a false GPS reading because of a firmware bug, nobody is accountable in the way that Motorola Solutions is accountable for Airwave failures. The liability question has no clean answer.

    Ofcom’s position is that licence-exempt bands can be used for this kind of deployment provided power limits are respected (25 milliwatts for most LoRa operation in the UK). They do not regulate what you do with the data. But the moment a volunteer network becomes load-bearing for life-safety operations, you would expect some regulatory framework to kick in. It has not. The NCSC has published guidance on operational technology security, and the relevant fire and rescue authorities have resilience planning obligations under the Civil Contingencies Act 2004, but nobody has drawn a clear line connecting those obligations to community-deployed mesh infrastructure.

    This mirrors a pattern you can see across several areas of UK critical infrastructure: the gap between what statutory bodies are required to provide and what actually exists on the ground gets quietly filled by volunteers and community groups, with no formal recognition and no formal oversight. The same dynamic appears in the way amateur radio operators provide emergency comms backup at major incidents, and in the way technically literate people in rural communities have built their own broadband infrastructure rather than wait for BDUK rollout. The pattern is worth understanding because it tells you something honest about where the state actually ends and informal resilience begins.

    Where this intersects with the wider security picture

    A community-deployed mesh network that carries even partial emergency coordination data is an attack surface. I would be failing in my job if I did not flag that. LoRaWAN has had well-documented security issues: early implementations often had poor key management, and replay attacks against LoRaWAN join procedures have been demonstrated in academic literature. Meshtastic encrypts channel traffic using AES-128, but the default shared key is public and many deployments never change it. A motivated attacker in range of a node could inject spoofed position packets or jam the 868 MHz band entirely with cheap hardware.

    This is not hypothetical. The same class of RF interference techniques that could disrupt a LoRa mesh have been used against GPS and GSM networks by state actors. For groups deploying these systems in a genuine emergency support role, the minimum sensible precautions are: change default encryption keys, document your network topology privately, and have a fallback plan that does not assume the LoRa mesh is intact. The techniques ransomware groups use to map UK critical infrastructure are exactly the kind of recon that could identify and target a poorly-secured community comms network, particularly one that has been publicised on social media by enthusiastic volunteers.

    There is also a data protection angle. If your LoRaWAN nodes are logging GPS tracks of emergency responders, that data is personal data under UK GDPR. Where is it stored? Who has access? Most volunteer deployments I have heard about have given this no thought at all. It is worth thinking about before the ICO does it for you. The parallel with how public-facing APIs can leak sensitive data, something covered in depth in the piece on UK government repositories leaking credentials and internal hostnames, is not flattering to anyone.

    None of this is an argument against what these communities are doing. It is an argument for doing it with your eyes open. The people deploying LoRaWAN emergency communications in rural UK are filling a real gap with real competence. They deserve better than a governance vacuum, and they deserve better than an infrastructure programme that has burned £11 billion without delivering reliable coverage to the places that need it most. Until one or both of those things changes, the soldering irons will stay lit.

    Frequently Asked Questions

    What is LoRaWAN and can it actually be used for emergency communications in the UK?

    LoRaWAN is a low-power wide-area network protocol built on LoRa radio modulation, operating in the 868 MHz licence-exempt band in the UK. It can transmit GPS coordinates, status codes, and short text messages over distances of 10 to 15 kilometres on open terrain, making it genuinely useful for tracking and alerting in areas where Airwave or 4G coverage fails. It cannot carry voice, so it complements rather than replaces radio comms.

    Is it legal to deploy LoRa or mesh radio nodes for emergency support in the UK without a licence?

    Yes, for most LoRa deployments. Ofcom permits licence-exempt use of 868 MHz at up to 25 milliwatts, which covers the vast majority of LoRaWAN and Meshtastic hardware. Amateur radio operators holding a full licence have additional options in other bands. The legal grey area is not spectrum licensing but operational accountability: there is no formal framework governing volunteer networks used in life-safety roles.

    What hardware do volunteer groups typically use for off-grid mesh comms?

    Common choices include Dragino and RAK Wireless LoRaWAN gateways (roughly £80 to £300) running ChirpStack or The Things Stack, and Meshtastic-compatible nodes like the LILYGO T-Beam or Heltec LoRa 32 (around £25 to £50 each). Solar-powered gateway installations are practical in rural settings and the whole infrastructure for a small coverage network can be built for under £500.

    How does Meshtastic differ from standard LoRaWAN for emergency use?

    Meshtastic creates a peer-to-peer mesh where every device acts as a repeater, so there is no single gateway that can fail. LoRaWAN requires at least one gateway connected to a network server. For emergency scenarios where infrastructure reliability is uncertain, Meshtastic’s decentralised architecture is more resilient, though it has lower throughput and the default encryption key is publicly known and must be changed before operational deployment.

    What are the main security risks of community-deployed emergency mesh networks?

    The key risks are: default encryption keys left unchanged (particularly on Meshtastic), no authentication of node identity, vulnerability to replay attacks on LoRaWAN join procedures, and susceptibility to RF jamming on the 868 MHz band. There are also UK GDPR implications if nodes log GPS tracks of responders without a lawful basis and a documented data handling policy. Operational security hygiene, changing defaults and limiting network publicity, is the minimum baseline.

  • 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 Ransomware Gangs Are Mapping and Exploiting UK Critical National Infrastructure: The Recon Techniques Targeting Energy, Water, and Transport Networks

    How Ransomware Gangs Are Mapping and Exploiting UK Critical National Infrastructure: The Recon Techniques Targeting Energy, Water, and Transport Networks

    Before any ransomware payload lands, there are weeks, sometimes months, of quiet, methodical reconnaissance. The gangs targeting ransomware UK critical national infrastructure CNI are not kicking in the front door. They are standing across the street with binoculars, taking notes, mapping every exposed service, every engineer’s LinkedIn profile, every misconfigured SCADA port that’s been breathing internet air since 2019. I’ve spent a lot of time reading through NCSC advisories and incident post-mortems, and the picture that emerges is genuinely unsettling. These groups are patient, technically competent, and frequently more organised than the organisations they are attacking.

    Industrial SCADA control room representing the attack surface targeted in ransomware UK critical national infrastructure CNI campaigns
    Photo by Daniel Ponomarev on Pexels

    Shodan isn’t a hacker tool, it’s a business intelligence platform for criminals

    Let’s start with the surface. Shodan, Censys, FOFA, and the newer BinaryEdge class of scanners index the entire IPv4 address space continuously. For a threat actor researching UK water utilities or electricity substations, these platforms return results in seconds. Filter by ASN, banner string, or geographic region and you can enumerate every publicly reachable Modbus port, every exposed DNP3 endpoint, every HMI login panel sitting on a routable IP.

    This is not hypothetical. The NCSC’s joint advisory on attacks against UK CNI operators, published in coordination with CISA and other Five Eyes partners, explicitly calls out Shodan-style passive enumeration as a consistent first stage in OT-targeted intrusions. What makes it worse is that many of these exposed services belong to vendors and third-party contractors, not the primary operators. A water treatment facility might have hardened its own perimeter, but the telemetry contractor running SCADA maintenance remotely has left a VNC instance open on port 5900 since the pandemic, and nobody noticed.

    The targeting is surgical. Search for "WAGO" country:GB port:502 on Shodan and you will find programmable logic controllers from a major German ICS vendor sitting on British industrial networks, some of them responding to unauthenticated Modbus read requests. That is not a theoretical attack path. That is an open door with a welcome mat.

    Spear-phishing OT engineers: the human layer of CNI recon

    Technical enumeration only gets you so far. The OT environment, the operational technology layer that physically controls pumps, turbines, rail switching gear, and grid infrastructure, is often air-gapped or at least segmented from the corporate IT network. Getting from an exposed corporate VPN to an engineering workstation running GE iFIX or Siemens WinCC requires either a supply chain compromise or a human being who crosses that boundary every day.

    That human is the OT engineer. And threat actors are very good at finding them.

    LinkedIn is the primary reconnaissance resource here, and it is shockingly effective. An engineer at National Grid or Yorkshire Water will often list their specific tooling, “Proficient in Wonderware SCADA”, “ABB DCS configuration”, in their profile. That tells an attacker exactly what software stack to build a lure around. From there, the spear-phish writes itself: a fake software update notification from the vendor, a spoofed invitation to a user group webinar, a malicious PDF disguised as an HSE compliance bulletin. I’ve seen real examples where threat actors registered convincing typosquat domains for major ICS vendors weeks before a campaign launched, which maps closely to the infrastructure burn patterns we’ve covered in UK phishing domain infrastructure.

    The spear-phish payload is typically a stager, something lightweight that establishes persistence and phones home for further instructions. Cobalt Strike, Brute Ratel, and increasingly custom loaders that evade signature detection. Once that engineer’s laptop is compromised, the attacker waits. They watch RDP sessions. They capture credentials. They map the internal network topology quietly, over weeks, before anyone touches the OT segment.

    What the NCSC advisories actually reveal about the CNI attack surface

    The NCSC publishes CNI-specific guidance and threat advisories, but you have to read them carefully because the really interesting details are in what they don’t say explicitly. The NCSC’s operational technology security collection describes a recurring pattern: attackers achieving initial IT network access months before any OT interaction is observed. The dwell time in UK CNI breaches is long. Measured in months, not days.

    That dwell time matters because it means conventional perimeter detection is nearly useless. By the time anyone looks at the logs, the attacker has already mapped the internal Active Directory, identified the historian servers that bridge IT and OT networks, and probably exfiltrated network topology diagrams from a SharePoint folder that was accessible to the entire organisation. The historian server is a consistent pivot point, it legitimately talks to both the corporate network and the control system network, which makes it an ideal beachhead that generates minimal anomalous traffic alerts.

    The NCSC’s advisories on specific nation-state actors, particularly the joint advisory on Sandworm-adjacent groups and the Volt Typhoon-linked activity against Western CNI, describe living-off-the-land techniques that make detection even harder. No custom malware. Just WMI, PowerShell remoting, and legitimate admin tools. The kind of traffic that blends into normal IT operations until someone with proper OT-specific anomaly detection is watching. Most UK CNI operators don’t have that, at least not at the OT layer. My reading of the NCSC’s own capability assessments suggests that detection maturity at the OT level is two to three years behind where it needs to be, and the advisory language is diplomatic about it in a way that should alarm anyone paying attention.

    The supply chain angle that nobody talks about enough

    Direct exploitation of CNI operators is hard. These organisations tend to have at least reasonable corporate IT security. But their supply chains are a different story. The ICS vendor doing firmware updates, the calibration company that visits substations quarterly with a laptop, the managed SOC provider with a monitoring agent installed across the estate, all of these are potential ingress points, and threat actors know it.

    This is the same dynamic we see in credential exposure across public repositories. UK government and NHS repositories leaking API keys and internal hostnames is a reminder that the supply chain attack surface extends to code and configuration, not just physical access. An ICS vendor whose developers commit VPN credentials to a public repo has just handed attackers a pass into every client network they maintain.

    The NCSC specifically flags Managed Service Providers as a high-risk vector in its CNI guidance. In 2026, with remote OT management now standard across most UK energy and water operators, the MSP attack surface for ransomware UK critical national infrastructure CNI targeting has grown considerably. A single compromised MSP with privileged access to multiple CNI clients is a force multiplier no ransomware gang can resist.

    What defenders are actually doing about it

    The honest answer is: not enough, fast enough. The NCSC’s Early Warning service and the broader threat intelligence sharing that happens through the UK’s CNI sector Information Sharing and Analysis Centres (ISACs) helps, but threat intel only matters if operators have the internal capability to act on it. Many smaller water and transport operators don’t have a dedicated OT security team. They have an IT manager and a SCADA vendor contract.

    The controls that actually work against the recon-heavy playbook described above are fairly well understood. Network segmentation that genuinely isolates OT from IT, with strict allowlisting on historian server traffic. Asset inventory that actually covers the OT layer, not just the corporate estate. Phishing-resistant authentication for remote access, passkeys and hardware tokens, not just SMS-based MFA that attackers have been bypassing for years. And crucially, monitoring at the protocol level inside OT networks, not just SIEM rules watching Windows event logs on the corporate side of the Purdue model boundary.

    The ransomware UK critical national infrastructure CNI threat is not going away. If anything, the economics are getting worse, higher ransom demands, more sophisticated affiliate networks, and nation-state actors pre-positioning in CNI networks for disruption rather than financial gain. The recon phase is where defenders have the most leverage, because patient attackers leave traces. Exposed services get fingerprinted. Spear-phish domains get registered. Credential-stuffing attempts hit authentication logs. The signal is there. The question is whether anyone is actually looking for it.

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

  • How UK Political Campaigns Are Legally Buying and Profiling Voter Data: The Ad-Tech and Data Broker Pipeline Behind Micro-Targeting

    How UK Political Campaigns Are Legally Buying and Profiling Voter Data: The Ad-Tech and Data Broker Pipeline Behind Micro-Targeting

    Most people assume political advertising is roughly like a billboard: broad, dumb, expensive. A party slaps up a poster near a roundabout and hopes for the best. What’s actually happening is considerably darker. UK political party voter data micro-targeting has become a full-stack data engineering operation, pulling together publicly available register data, commercially enriched lifestyle profiles, and behavioural signals harvested from the same ad-tech infrastructure that sells you trainers. I’ve spent time pulling this apart, and the picture is not pretty.

    Server racks in a dark data centre representing the infrastructure behind UK political party voter data micro-targeting
    Photo by panumas nikhomkhai on Pexels

    Where the raw data comes from: the open register loophole

    The electoral register exists in two versions. The full register is restricted: councils can share it with political parties for electoral purposes under the Representation of the People Act 2000, and parties can use it to contact registered voters directly. The open register is something else entirely. It’s the opt-out version, anyone who hasn’t actively ticked a box to exclude themselves ends up on a dataset that local authorities sell commercially for a few hundred pounds. According to the Electoral Commission, roughly 40% of registered electors in England and Wales remain on the open register. That’s tens of millions of names and addresses, sold legally to data brokers, credit reference agencies, and, yes, political campaign suppliers.

    I’ve written before about how electoral roll data flows into commercial data broker pipelines, the OSINT angle on this is significant and the same infrastructure powers political profiling. The open register feeds into commercial enrichment layers. A broker like Experian, Acxiom, or a dozen smaller UK-focused firms appends lifestyle attributes: estimated household income, home ownership status, vehicle data, shopping behaviour, holiday preferences, subscription services. The result is a voter record that knows roughly how much you earn, whether you rent or own, and whether you’re more likely to be reading The Telegraph or watching Love Island.

    How parties enrich and segment those records

    Raw name-and-address data is only the start. Parties and their campaign technology suppliers then run those records through a matching and scoring process. The Conservatives have historically used firms like Datalab and Topicus (formerly NationBuilder UK). Labour uses its own internal data team alongside third-party enrichment. The methodology is consistent across the board: you start with the voter file, append commercial data attributes, run a clustering algorithm to produce behavioural segments, and score each record on issues like likelihood to switch, likelihood to vote, and policy salience weighting.

    The scoring models are where it gets technically interesting. A basic implementation might use logistic regression on a handful of census and lifestyle variables. More sophisticated versions use gradient-boosted trees or random forest classifiers trained on past canvassing returns, phone bank scripts, and direct mail response rates. Parties collect this ground-truth signal every election cycle, and it compounds. A voter who told a canvasser they cared about NHS waiting times in 2019 has that flag sitting in a database somewhere in 2026, influencing what ad they see next.

    Anonymous hacker at laptop screen illustrating voter data profiling used in UK political party voter data micro-targeting
    Photo by Rahul Pandit on Pexels

    Building lookalike audiences on Meta and Google

    Here’s where it gets genuinely uncomfortable. Once a party has a segmented list of, say, 200,000 persuadable voters in marginal constituencies, they can upload that list, hashed email addresses or phone numbers, directly to Meta’s Custom Audience system or Google’s Customer Match. Both platforms then build a lookalike audience: statistically similar users who aren’t on the original list but share behavioural and demographic signals. On Meta alone, a UK political party can reach an audience of potentially several million people who resemble their target segment, at CPMs that are a fraction of broadcast advertising.

    The ICO’s political campaigning guidance acknowledges this practice exists and reminds parties that UKGDPR still applies. But the guidance stops well short of prohibiting it. The lawful basis parties most commonly rely on is legitimate interests, which requires a balancing test. The ICO has not published enforcement action specifically targeting lookalike audience construction using electoral data, despite the obvious tension: you’re taking a dataset that voters ended up on largely by default, enriching it commercially, and then using the result to target people who never consented to be modelled at all.

    Where the ICO’s guidance goes quiet

    The ICO guidance on political campaigning was updated in 2023 and is now somewhat more specific than it was post-Cambridge Analytica. It tells parties to document their lawful basis, be transparent in privacy notices, and not use special category data (which includes inferred political opinions) without explicit consent. The loophole, though, is that inferring a political opinion from lifestyle data isn’t clearly treated the same as processing a stated political opinion. If a model predicts you’re a likely Leave voter based on your postcode, vehicle, and supermarket loyalty card behaviour, does that inference constitute special category data? The ICO has not given a clean answer. The Article 9 question is live and unanswered.

    There’s a secondary gap around data retention. Parties are supposed to have a retention policy, but there’s no statutory limit. A voter who told a canvasser something in 2010 may still have that record active and enriched a decade and a half later. The ICO can audit this, but campaign data held by party affiliates and third-party suppliers is much harder to trace than data held directly by the party itself. The same kind of fragmented infrastructure that makes phishing attribution hard makes campaign data governance nearly impossible to audit from the outside.

    The ad-tech infrastructure running underneath it all

    Political micro-targeting in the UK doesn’t run on bespoke kit. It runs on the same ad-tech stack as every other digital advertiser. Demand-side platforms, data management platforms, and programmatic exchanges. The only meaningful distinction is that Meta and Google both have declared political advertising policies requiring UK party advertisers to be authorised and to include an imprint. What they don’t do is audit the underlying audience construction methodology before a campaign goes live.

    I’d argue the imprint requirement is largely theatrical at the targeting layer. You can see who paid for an ad. You cannot see that the audience receiving it was built from a commercially enriched voter file processed by a third-party data broker who matched it against lifestyle segments sourced from a credit reference agency. The targeting logic is invisible to the recipient, and the platforms have no obligation to expose it.

    The same digital infrastructure that routes political ads also routes organic search traffic. Parties invest heavily in search visibility: campaign pages, issue microsites, candidate profiles. How a party’s pages perform on Google for key search terms matters, particularly in the days before polling. Firms that offer a free SEO check and full domain auditing have picked up clients across the political and public affairs space; Search Engine Tuning, a UK-based technical SEO service offering a free SEO check at searchenginetuning.co.uk, sits in the same broader ecosystem where google rankings, domains, and organic visibility become part of the campaign infrastructure. Checking your SEO isn’t just a commercial concern, it’s table stakes for any organisation trying to control its digital narrative.

    What you can actually see about your own profile

    Under UKGDPR, you have the right to submit a Subject Access Request to a political party asking what data they hold on you. In practice, the responses are often thin. Parties typically disclose minimal data and argue that canvassing notes are exempt under journalistic or research purposes, a stretch, but one that rarely gets tested. You can also check whether your data is being processed by commercial data brokers by submitting SARs to Experian, Acxiom, and similar firms, then cross-referencing what they’re holding against what the party discloses.

    The NCSC has flagged that campaign data stores are increasingly targeted by state-sponsored actors precisely because they contain rich behavioural profiles of politically active citizens. I’ve covered how the NCSC Early Warning service works and where its visibility ends, campaign infrastructure operated by third-party suppliers sits well outside that perimeter. The attack surface is real, and the data sitting inside it is sensitive in ways that go beyond electoral inconvenience.

    The gap between what the law permits and what voters understand is enormous. The ICO has the powers to act. Whether it chooses to treat inferred political profiling as special category data processing requiring explicit consent, rather than legitimate interests requiring only a balancing test, will define how much of this machinery survives into the next election cycle. Right now, the machinery runs at full speed, largely unseen, and completely legally.

    Frequently Asked Questions

    Can UK political parties legally buy voter data?

    Yes, within limits. Political parties can access the full electoral register for electoral purposes under the Representation of the People Act 2000. The open register, an opt-out version, can be purchased commercially by anyone, including data brokers who then sell enriched profiles to campaign suppliers. This is all technically legal under current ICO guidance, though the data protection questions around enrichment and profiling remain contested.

    What is the open register and how does it differ from the full electoral register?

    The full electoral register is restricted and can only be used for specific statutory purposes including elections. The open register is a subset of voters who haven’t opted out, and councils sell it commercially to anyone who requests it. Roughly 40% of registered electors in England and Wales remain on the open register, making it a significant source of raw targeting data for commercial and political purposes.

    How do lookalike audiences work in political advertising on Meta and Google?

    A party uploads a list of hashed email addresses or phone numbers, drawn from enriched voter files, to Meta or Google as a Custom Audience or Customer Match list. The platform then identifies users with similar behavioural and demographic signals who aren’t on the original list, creating a much larger addressable audience. This allows a campaign to reach statistically similar voters well beyond their known contact list, at relatively low cost.

    Does the ICO regulate political micro-targeting in the UK?

    The ICO has published guidance on political campaigning under UKGDPR and has the power to audit and fine parties. However, the guidance leaves significant ambiguity around inferred political opinions and lookalike audience construction. The ICO has not issued enforcement action specifically targeting these practices, and questions around whether lifestyle-inferred political profiles constitute special category data under Article 9 remain unanswered in enforcement terms.

    Can I find out what data a political party holds on me?

    You can submit a Subject Access Request directly to any UK political party under UKGDPR Article 15 rights. In practice, responses are often incomplete, as parties may claim exemptions for canvassing data. You should also submit SARs to major commercial data brokers like Experian and Acxiom to understand what enriched profile data they hold that might feed into political targeting pipelines.