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