Why your MTD software asks for your device details

The question nobody answers honestly

At some point in setting up Making Tax Digital software, a careful person notices that the app has read their screen size, or asks the browser for permission to do something, and wonders: why does my tax software need to know about my computer?

The usual answer is a shrug, or a line about “security”. The real answer is specific, and we can give it, because we send this data four times a year and had to argue with HMRC about one piece of it. So here is what actually leaves your machine when you file, why HMRC wants it, and the one part that is genuinely worth a second thought.

What is a fraud prevention header?

It is data about the device and connection that made an API call, attached to that call. HMRC requires a set of them on every Making Tax Digital request, and is blunt about the standing: “You are required by law to submit header data for the VAT (MTD) and Income Tax Self Assessment (MTD) APIs.”

This is not a nice-to-have that vendors compete on. A provider whose software continues to send missing or incorrect header data, after discussions with HMRC, can be fined and blocked from HMRC's APIs. The data is checked by a specialist team before a provider is allowed anywhere near real filings.

The purpose is a fingerprint. HMRC wants to know the shape of the machine that filed as you, so that if someone else later files as you from a different machine, the shape will not match. That is a defensible thing for a tax authority to want. It is also a thing you were never told about before you clicked connect.

Exactly what we send HMRC about you

Our connection method is called WEB_APP_VIA_SERVER: a website whose server files on your behalf. For that method we send fourteen headers. Ten describe you and your connection. Read them as a landlord, not an engineer.

The other four are about us, the provider, not you. HMRC wants to know which software filed, in what version, and from where.

Notice what is not there. No contents of your return beyond the figures you are filing. No browsing history. No files. It is a description of the machine and the moment, not of your affairs.

The header that made us build a server

One of those fourteen has a story, and it is the most honest illustration of what this regime actually costs. Gov-Client-Public-Port is the TCP source port of your connection: the number your computer picks for its end of the conversation. HMRC wants it alongside your IP address, and is strict that it must be your port: “This must not be a server port, for example 80 for http connections and 443 for https connections.”

Here was our problem. Our API sits behind Cloudflare's global edge. By the time a request reaches our own code, your original connection is long gone: Cloudflare accepted it and opened a fresh one to us. The source port HMRC wants was never ours to see. HMRC even acknowledges this happens: “some popular load balancers do not” preserve it.

For a time we omitted the header and told HMRC why, using its own missing-data route. In July 2026 HMRC's review asked us to populate it. So we built one: echo.letsort.co.uk, a small reverse proxy we operate that your browser connects to directly, with no Cloudflare in front. It terminates your connection itself, reads your public IP and source port straight off the accepted socket, notes the moment, and hands all three back. We disabled HTTP/3 on it so the port is always a TCP source port, as the spec requires.

HMRC's specification permits exactly this. It says collection of your public address “could be at the Web Application Firewall (WAF), load balancer, reverse proxy or the server process itself”. A reverse proxy is on that list. Your IP, your port and the timestamp all describe one connection from your device. On the rare request where the echo cannot be reached, we drop the port rather than send a placeholder.

This is the real cost of the regime. A landlord pressed one button. Behind it, a vendor stood up a dedicated piece of infrastructure whose sole purpose is to observe the port your browser dialled out from, because a tax authority asked. You will not see it, and you are paying for it in the price of every compliant product.

The two headers we deliberately do not send

HMRC is blunt that you must submit data for every header your connection method lists, and that you are required by law to do so. It does not call any of them optional. But for a few, its own guidance describes named circumstances in which you will not be able to collect a value, and then tells you to follow its missing-data guidance rather than invent one. Two of those apply to us, and we have told HMRC exactly why we omit them.

The honest move here is to declare the omission, not to paper over it. Sending an empty or invented value to make a checklist look complete is exactly what a fraud prevention regime is meant to catch. We told HMRC's specialist team which headers we omit and why, on the record, under a support ticket. If you want to read the full filing sequence these headers ride along with, we wrote that up separately.

So is this a privacy problem?

It is a fair question, and the honest answer is: mostly no, with one part worth sitting with. What reaches HMRC is a description of the device and connection that filed, used to detect impersonation. It is not the contents of your tax affairs beyond the figures you are submitting anyway, and it is not your browsing or your files.

Nor is it something you opted into that could be quietly abused. HMRC requires the data by law, which is why, in data-protection terms, our basis for processing it is a legal obligation rather than consent you gave and could have withheld. A vendor cannot decide to collect more than the spec, or use it for marketing, and stay compliant.

The part worth sitting with is the honest one: this is, however benign the intent, surveillance of your device, and it now includes infrastructure a vendor runs specifically to watch your connection. The right response is not alarm; it is to ask a vendor the plain question. Do you send accurate header data, and do you store as little of it as you can? A vendor that cannot answer clearly is telling you something.

What this tells you when you choose software

Fraud prevention headers are a rare, honest signal in a market full of unverifiable “HMRC approved” claims. Getting them right is not cosmetic. HMRC requires them in sandbox calls before it grants production access, says they “will be checked by a specialist team”, and can fine and block a provider that keeps sending wrong data. A vendor that has cleared that bar has done real work you can ask about.

Three questions cut through the marketing. Which connection method do you use? Do you send every header that method requires, or quietly skip the awkward ones? And have you completed HMRC's production approval, including the fraud prevention review? Vague answers to precise questions are the tell.

Common questions

Sources

All from HMRC's developer hub. The behaviour described is our own code; the quoted wording was checked live on 21 July 2026. HMRC's main fraud prevention guidance shows a last-updated date of 27 January 2025 and keeps a dated change log, while some adjacent pages carry no date, so the quotes are stated as at the day we checked.

• HMRC: send fraud prevention data (the legal requirement, and the fine-and-block)
• HMRC: fraud prevention, web app via server (the header list and the conditional-omission wording)
• HMRC: Gov-Client-Public-Port (must not be a server port such as 80 or 443)
• HMRC: Gov-Client-Public-IP-Timestamp (collection at the WAF, load balancer, reverse proxy or server)
• HMRC: how to integrate (production approval, and the specialist-team header check)

Related

• What actually happens when your software files an MTD update
• The landlord's compliance year: every date that actually matters