01 · .p12 certificate
AES-256-GCM encryption before storage · R2
Trust is not declared.
It can be followed.
An invoice, a certificate and an account go through different controls. This report gathers the layers Cofactu implements and the places where you can check them.
Strong authentication · Encrypted certificate · Chained record · Data in the EU
See the evidence ↓Four controls for
four different surfaces.
Protection is not a list of acronyms. Each layer applies to a specific object and can be tied to a product responsibility.
| Layer | Evidence | Control | Source | |
|---|---|---|---|---|
| 01 | Identity | TOTP and passkeys | The product supports strong authentication with TOTP and passkeys. Sensitive owner operations require one of those two forms of authentication. | Strong authentication for owners |
| 02 | Certificate | AES-256-GCM · R2 | The .p12 certificate is encrypted before it is stored in Cloudflare R2. The worker decrypts it in memory when it needs to authenticate a communication with the AEAT (Spanish Tax Agency). | Certificate vault |
| 03 | Tax record | Chained SHA-256 | Each VeriFactu record carries the SHA-256 hash linked to the previous record. The communication with the AEAT is authenticated with an electronic certificate. | VeriFactu evidence |
| 04 | Residency | Neon EU · Frankfurt | The database runs in Neon's European region, in Frankfurt. The public DPA (data processing agreement) identifies the sub-processors and their location. | DPA and sub-processors |
Evidence file From the technical control
From the technical control
to the surface where you check it.
A readable summary of the mechanisms behind the product. The linked routes lead to the related documentation or settings.
An invoice chain does not replace account security, and certificate encryption does not replace control over data processing.
Each piece of evidence answers a different layer.
A certificate only appears
when the AEAT must identify you.
02 · Submission worker
Decrypted in memory to authenticate the connection · mTLS
03 · VeriFactu record
SHA-256 chained to the previous record · Record
The certificate you upload is stored encrypted. When an invoice is submitted, the worker uses it in memory to authenticate the connection; the record hash is chained separately to the previous record.
Representation of a product capability; not a real-time status panel.
Questions about controls, data and traceability.
Answers based on Cofactu's current capabilities and public documents.
Read the DPA →Does Cofactu support two-factor authentication?
Yes. Cofactu includes TOTP and passkeys. For sensitive owner actions, the middleware requires one of those forms of strong authentication before it allows the operation.
How is the digital certificate protected?
The .p12 certificate is encrypted with AES-256-GCM before it is stored in Cloudflare R2. The worker decrypts it in memory only to authenticate the communication with the AEAT that you have instructed, and does not write it to logs.
What proves the integrity of a VeriFactu invoice?
The record includes a SHA-256 hash chained to the previous record. In VeriFactu mode it does not need an individual XAdES signature: the communication with the AEAT is authenticated with a certificate.
Where can I read the data processing agreement?
Cofactu's public DPA names Codificado SL as the processor and lists the sub-processors, including the Neon database in eu-central-1, Frankfurt.
Security you can review Run the check before you
Run the check before you
entrust the next record.
Read the DPA, check the VeriFactu documentation and decide with evidence you can locate.
DPA · Responsible declaration (declaración responsable) · Service status
