How WeFile Encrypts Your Data — And What That Actually Means for You

When you file a CT600 with WeFile, you hand us two things that matter enormously: the credentials that let us file on your behalf, and the financial story of your company. Neither is something you would leave lying around.

We have just published a dedicated Encryption and Data Protection page setting out exactly how those things are handled. This article is the longer version — what we encrypt, what we deliberately never store, who can and cannot see your credentials, and, just as importantly, what encryption does not protect you from.

We have tried to write it the way we would want a supplier to write it to us: specific, with the limits included.

Corporation tax filing software holds an unusual combination of data. Most software holds one or the other; filing software holds both.

Filing credentials. To submit a return, HMRC needs a Government Gateway user ID and password enrolled for Corporation Tax, and Companies House needs the company's authentication code. These are live keys to your statutory filing position. In the wrong hands, someone could file against your company.

The credentials are secrets. They get encrypted.

Financial figures. Your profit and loss, balance sheet, director loans and tax computation. Commercially sensitive, but also data the software has to read, add up, validate, cross-check against HMRC's rules and render into iXBRL. Figures that were encrypted in a way nobody could read would make the product impossible.

So the honest position is: credentials are encrypted at field level, figures are not, and we say so plainly rather than implying everything is sealed in a vault.

The Government Gateway password and the Companies House authentication code are encrypted with AES-256-CBC before they are written to our database. Three details make that meaningful rather than a badge:

• A fresh random initialisation vector for every value. Two users with the same password produce completely different ciphertext, so nothing can be inferred by comparing stored records.
• The key lives only in our server environment. It is derived from a secret that is never written into the database. A copy of the database on its own — a stolen backup, a leaked dump — does not reveal a single credential.
• Decryption happens at the last possible moment. The plaintext exists only in memory, in the instant a return is transmitted to HMRC's GovTalk service or to Companies House. It is not decrypted to display a dashboard, run a validation, or build a PDF.

Some fields alongside them are stored unencrypted, deliberately: the Government Gateway user ID, the company UTR, and the name of the director signing the declaration. Those are identifiers rather than secrets — the system needs to read and validate them, and encrypting an identifier that has to be checked on every screen buys nothing while making the product slower and more fragile.

Encryption at rest is only half the answer. The other half is who the application is willing to hand a decrypted value back to. Our rule is that a credential is revealed to exactly one party: the person who entered it, in their own signed-in session.

That third row is the one we are most often asked about. When our support team steps into your account to diagnose a rejection — something we do frequently, because it is the fastest way to solve a filing problem — we can see your figures, your submission history and HMRC's response, but the password and the authentication code come back redacted. We can help you file without ever being able to read the keys that do the filing.

There is one exception, and it is a structural one rather than an oversight. If you file through an accountant's branded WeFile portal, that firm is acting as your filing agent: they entered the credentials or were given them for that purpose, and they can see the credentials held against filings in their own portal. That is the relationship you have with your accountant, not a gap in ours.

The strongest form of protection is not storing something at all, so we make it easy to reach that position.

Delete them whenever you like. Stored credentials can be removed from the web app, or through the developer API with POST /v1/filing/credentials/delete. The only time deletion is refused is while a submission is genuinely in flight — pulling the credentials out from under a transmission that is mid-flight would leave a filing in an unknown state.

Or never store them. Developer-API integrators can supply credentials with each individual submission request. In that mode they are held in memory for that one transmission and never written to our database at all. For firms with their own credential vault, this is usually the right integration: keep the secrets where you already keep secrets, and pass them through only at the moment of filing.

The same AES-256-CBC field encryption is applied wherever else we hold something that behaves like a key:

• HMRC Making Tax Digital VAT tokens. When you connect a company for MTD VAT, the OAuth access and refresh tokens are encrypted. A refresh token is a long-lived key to your VAT account, so it is treated exactly like a password.
• White-label partner payment and email credentials. Partners running a branded portal supply their own Stripe secret key and their own SMTP host, username and password so that client payments and emails come from them. All of those are encrypted at rest.

Three categories of data pass through WeFile and are never persisted. This is design, not omission.

• Accounting-software access tokens. When you import a trial balance from Xero, QuickBooks Online or FreeAgent, the access token is used for that import session and is not saved to our database. We pull the figures you asked for; we do not keep standing access to your ledgers.
• Filing documents. Your CT600 PDF, your iXBRL accounts and your tax computation are generated on demand every time you ask for them, from the figures in your filing. There is no document store of finished returns sitting around to be exfiltrated. It also means the document you download always reflects the current state of the filing.
• Card details. Payments run through Stripe. Full card numbers never reach our servers, so there is nothing card-related for us to protect.

Your WeFile account password is not encrypted — and that is the correct answer, not a weaker one. It is hashed one way with bcrypt. Encryption is reversible by design; a password should not be. Because it is hashed, nobody at WeFile can read or recover your password. It can only be reset.

Two-factor authentication using a time-based code from an authenticator app is available on every account, and we recommend turning it on. If you file for other people's companies, treat it as mandatory.

Developer API keys are stored as bcrypt hashes as well, and the full key is shown exactly once, at the moment you create it. If you lose it, you generate a new one — we cannot look it up for you, because we do not have it.

The whole of WeFile — the site, the developer API and the white-label portals — is served over HTTPS/TLS. Outbound submissions to HMRC's GovTalk service and to Companies House are made over TLS as well.

Every hop your data takes, from your browser to us and from us to government, is encrypted in transit.

This is the part of the design we are proudest of, because the obvious approaches force a choice between evidence and security.

You need to be able to prove, potentially years later, exactly what was submitted on your behalf. So we retain the exact envelope that was transmitted. But that envelope contains credentials — the sender ID, the authentication value, the Companies House authentication code — and keeping those in a permanent log would undo everything above.

So we split it:

• The credential elements are replaced with [REDACTED] before the envelope is stored.
• The return itself is retained verbatim, alongside a SHA-256 digest of it.
• HMRC's signed IRmark receipt is stored in full.

The result is a submission that stays independently verifiable — the digest proves the retained body is byte-for-byte what was hashed, and HMRC's own receipt proves what they accepted — while the secrets that transmitted it are not sitting in the audit log. Evidence and confidentiality, without trading one for the other.

Some filings involve attachments — a charity's accounts PDF, or a document sent to our support team on a ticket. Those are held in Cloudflare R2 object storage, encrypted at rest by the storage provider, and referenced by long, unguessable URLs.

Two pieces of straight advice: treat those links as private and do not forward them, and do not upload documents you do not actually need to send us. The safest document is the one that was never uploaded.

Every security page should have this section, and most do not.

It is not end-to-end encryption. Field-level encryption protects a stored secret against someone who obtains the data. It is not a scheme in which only you hold a key and we are mathematically unable to see anything — a filing product that validated nothing and computed nothing would be no use to you.

It does not protect a compromised account. If someone gets into your WeFile login, the application will happily do for them what it would do for you. No amount of encryption at rest changes that. This is precisely why two-factor authentication matters more than any cipher we could name.

Your figures are not field-encrypted. Profit and loss and balance sheet data can be read by authorised WeFile staff when investigating a filing you have asked us to look at. We would rather tell you that than let you assume otherwise.

Encryption is not a compliance certificate. We describe our engineering, not an accreditation. WeFile Limited is registered with the ICO (registration ZC104632), and how we handle personal data is set out in our Privacy Policy.

Accountants and bookkeepers carry other people's filing credentials, which raises the stakes considerably. A few things follow from the design above:

• Per-client credentials stay per-client. They are encrypted against the individual filing, not pooled into one shared store.
• Your team's access is your team's access. WeFile staff cannot read the credentials you hold, including when we are helping you with a rejection.
• You can operate with nothing stored. Via the developer API, submit credentials per request from your own vault and we keep none of them.
• You can prove what you filed. The redacted envelope, verbatim body, SHA-256 digest and IRmark receipt give you a defensible record for each client without holding secrets in your audit file.
• Enable 2FA across the practice. It is the single highest-value control available to you, and it takes two minutes per user.

One note for firms doing due diligence: Companies House submissions are made through WeFile's own presenter account. We do not currently support filing under a firm's own presenter credentials.

1. Turn on two-factor authentication. Profile settings, two minutes, and it defeats the most realistic attack against you.
2. Use a unique password for WeFile, ideally from a password manager. Reused passwords are how accounts get taken over.
3. Delete stored credentials on filings you have finished with, if you would rather we held nothing.
4. Do not email credentials to anyone — including us. We never need your Government Gateway password to help, because we cannot read it anyway.
5. Review who has access to your account and, if you are a firm, to your team and portal.

The full detail, kept up to date as the product changes, lives on our Encryption and Data Protection page. Our security settings are where you will find two-factor authentication.

If you have a question about any of this, or you believe you have found a vulnerability, please email us directly at info@wefile.co.uk rather than disclosing it publicly. We would much rather hear about it from you first, and we will always tell you what we found and what we changed.

WeFile Limited, company number 17080509, 20 Wenlock Road, London, England, N1 7GU.