HMRC requires penetration testing. It has never checked whether you did one.

HMRC requires you to penetration test your MTD software. It has never once checked whether you did.

What you actually agreed to

To move from HMRC's sandbox to production, you accept the Developer Hub Terms of Use. Most people read them once, at the end of a build, when the only thing that matters is getting credentials issued. Two lines in them are worth going back for.

The first is the requirement itself:

The second is the question HMRC puts to you directly:

Note the word regular. Not once, not at launch. And note that HMRC names the independent third party route itself, without attaching any accreditation requirement to it. There is no mention of CREST, CHECK, or any named scheme anywhere in the terms.

What HMRC actually verifies

This is where the gap opens. HMRC's production approval process is genuinely rigorous about one thing and silent about another.

Fraud prevention headers: checked by a person

Before you get production credentials, HMRC must see evidence that your software sends fraud prevention headers, and must be satisfied with their level of accuracy. You submit your sandbox application credentials so HMRC can review your logs, and a specialist team reads the header data in your test calls. You test across different user IDs, devices, browsers and screen sizes. If it is wrong, you do not go live.

That is real verification, done by humans, against real traffic. Credit where it is due.

Security testing: not part of the process

Penetration testing appears nowhere in the production approval process. There is no evidence to submit, no report to upload, no assessor, no certificate and no renewal date. The approvals checklist is a questionnaire you complete about your own application, and approval depends on the checklist being completed satisfactorily and aligning with your API testing.

So the honest summary is this. HMRC checks that your software can talk to HMRC correctly, and that it sends the anti fraud metadata correctly. It does not check who inside your product can reach what.

What this does not mean

Three things, because the argument is weaker if it is overstated.

• It does not mean HMRC is negligent. HMRC recognition is an integration and conformance process. It was never advertised as a security audit, and it does not claim to be one.
• It does not mean a scanner is against the rules. The terms explicitly permit penetration test tools as an alternative to a third party. If you run a scanner, you are inside the wording.
• It does not mean your software has a problem. Nothing here is a finding about anyone. It is a statement about what has and has not been looked at.

Why the gap is where the expensive problems live

An automated scanner is good at the things that look wrong in isolation. An outdated library, a missing header, a known vulnerable version. It is structurally incapable of finding the class of problem that costs the most, because those problems require knowing what the rule was supposed to be.

A scanner cannot tell you that a paid feature is enforced in the interface and not on the server, because nothing about the response looks broken. The endpoint answers normally. It returns a two hundred. It just answers to an account that never paid.

We found exactly that on a live UK tax platform. An account with no subscription reached four endpoints that all responded normally, and one of them accepted a real tax return submission. It had been live for months. The developers were competent and had no idea. The platform had passed HMRC recognition, because passing HMRC recognition has nothing to do with it.

The full sequence, including the five further findings that turned up while verifying the fix, is on the proof page.

What to do about it

Nothing dramatic. Three questions, and you can answer all of them this week without spending anything.

• When did you last run against HMRC's validator? HMRC publishes a free Test Fraud Prevention Headers API. Your headers were checked once, at approval, on sandbox traffic. The question is whether production still matches.
• What did you answer on the penetration testing question? Go back and look. If the answer was a tool, find out when it last ran and what it covers.
• Can an account that has not paid reach a paid feature?This is the one worth thirty minutes of a developer's time today. Not through the interface. Directly against the endpoint.