Advanced Architecture
Cryptographic Assurance: Audit Chains and Document Signing
When external auditors demand proof, static PDFs are not enough, they must be provably unaltered and traceable. EuroCompliant provides defense-grade non-repudiation: every audit log entry is SHA-256 hash-chained to its predecessor, and every generated legal declaration (e.g. EU Declaration of Conformity, CE Marking Guide) is cryptographically signed via Ed25519 and, on Enterprise, PAdES-embedded via superadmin key custody. Anyone can verify authenticity instantly at /verify/document/{id} without logging in.
Transcript
At some point an auditor, a regulator or a large customer will ask you to prove your records are genuine. A file on its own proves little, because anyone can edit a file. EuroCompliant seals every document you generate and records every action in a tamper evident trail.
Here is the whole process. Finish the checklist for a high risk system, lock it, and generate the EU Declaration of Conformity. When you download the PDF, EuroCompliant seals it automatically and shows a signed confirmation with a verification link.
The audit trail works the same way. Each entry is linked to the one before it, so nothing can be quietly edited or deleted. One click checks the whole history and confirms it is intact.
Every sealed document carries a verification link. Open it in any browser, with no login and no account, and you get instant proof that the document is unaltered and that your records were intact when it was sealed. Send the link to your regulator or your customer and they can check it themselves.
You never handle keys or certificates. EuroCompliant manages all of that for you, and if a signing key is ever replaced, your older documents stay verifiable, because each one carries its own proof.
That is the difference between asking people to trust you and letting them verify you. Genuine documents, intact records, and proof available in seconds.
Why this is required
EU AI Act Article 12 requires high-risk systems to technically allow automatic recording of events over their lifetime, ensuring traceability appropriate to the intended purpose. A log that can be edited, deleted or reordered without detection does not meet that test. Accountability therefore demands tamper-evidence, not just retention.
Article 47 (EU Declaration of Conformity) and Article 48 (CE marking) produce legal declarations that leave your trust boundary. A regulator, customer or court must be able to establish that the bytes they hold are exactly what your platform generated, on the date it claims, by the organisation it names, without trusting your database or your login. That is non-repudiation, and it requires asymmetric signatures, not just a pretty PDF.
DORA Article 17 (ICT-related incident reporting and log retention) and NIS2 Article 23 (cybersecurity incident reporting) similarly require that audit trails remain intact and auditable by a competent authority. A break in the chain must be detectable, and the verification must be performable by an external auditor without privileged access.
Key custody matters legally. If the signing key were per-tenant or self-managed without recovery, loss or rotation would invalidate historical proofs. Centralised superadmin custody (admin_document_signing.py, signing_keys.py) with Ed25519 key generation, rotation history and fingerprint publication solves this while preserving per-document verifiability.
What EuroCompliant does
The SHA-256 hash-chained ledger, Every row in AuditLog stores previous_hash (the current_hash of the prior log entry for that tenant) and current_hash = SHA256(previous_hash || company_id || action || resource_type || resource_id || details || metadata || created_at). The genesis hash is 0*64. Verification (Settings → Audit → Verify Chain Integrity, or GET /audit/verify) recomputes the entire chain from genesis to tip; any edit, deletion or reordering of a historical entry breaks the chain from that point forward and the UI reports Chain Intact vs TAMPERING DETECTED with broken_at_id.
Ed25519 digital signatures, When a PDF is generated (Compliance & Docs → Generate) and the checklist is locked, the backend's document_signing.py signs the canonical document bytes with the active Ed25519 private key held in SystemSetting document_signing_key (fingerprint, public_key_pem, generated_at, source, history). The DocumentSignature row stores signature_b64, public_key_pem, key_fingerprint (sha256: + 64 hex), content_hash, audit_chain_tip_hash and sealing_cert_fingerprint at generation time. Each document carries its own public key snapshot, so rotation never invalidates old documents.
PAdES embedding (Enterprise), On Enterprise, the same generation also embeds a real PAdES digital signature inside the PDF via an RSA-2048 X.509 certificate (certificate_pem / cert_private_key_pem in the same SystemSetting blob). The PDF's embedded signature is visible in any PDF reader as a document certification, while the sidecar Ed25519 signature is used for platform verification. Both are generated together via admin_document_signing.py's get_active_cert_signer.
Public verification without login, External auditors open /verify/document/{verification_id} (the X-Verification-Url header returned on PDF download, or the Verify → link in the document preview modal). The page shows Step 1: Ed25519 signature validity (recomputed content_hash vs stored signature_b64 via public_key_pem), Step 2: audit-chain integrity at signing time (audit_chain_tip_hash recomputed and compared), and Step 3: key provenance (fingerprint, generated_at). No authentication is required; the proof is self-contained. The verification page also displays the certificate's SHA-256 fingerprint for out-of-band confirmation.
Sealed PDFs carry a visible badge, Generated PDFs show an Ed25519 cryptographic signature badge (Document → Signed → Verification URL) when signing is enabled for the tenant's plan (Business+). The badge is not the security guarantee itself; the verification page is. The badge simply signals that a verifiable signature exists and where to check it.
Deadlines
Walking through it
Lock the checklist and generate the declaration
In Compliance & Docs, complete 100% of the checklist items for a high-risk system, lock the checklist (Art. 43 conformity lock), and generate the EU Declaration of Conformity (Art. 47). On download, the PDF is automatically digitally signed; on Enterprise, also PAdES-sealed. The preview modal shows the Signed badge and the Verify → link.
Open /compliance-docs →Inspect the hash chain in the audit trail
Navigate to Settings → Audit. The banner shows Cryptographic Log Integrity: Verified, N records checked (SHA-256 hash chain). Click Verify Chain Integrity to recompute from genesis to tip; the result is live, not cached. If intact, the banner turns green; any tamper shows red with the broken log ID.
Open /settings/audit →Verify as an external auditor, incognito, no login
Copy the public verification URL (/verify/document/{id}) from the PDF's footer or the preview modal's X-Verification-Url header, open it in an incognito tab, and confirm three green checks: signature valid, audit chain intact at tip, key fingerprint matches. Send that URL to your regulator or customer; they need no EuroCompliant account to verify.
Open /verify/document/{id} →Manage keys as superadmin
As superadmin, open Admin → Document Signing to view the active Ed25519 fingerprint, X.509 sealing fingerprint, history (last 10), and to generate or import a new key. Rotation archives the old public key but never invalidates documents signed with it, because each DocumentSignature carries its own snapshot.
Open /admin/document-signing →The law
Record-keeping
Automatic recording of events over the system's lifetime, ensuring traceability appropriate to its intended purpose, the legal driver for the hash-chained ledger.
EU declaration of conformity
A written, machine-readable declaration per high-risk system, retained for ten years, the document class that is digitally signed.
CE marking
Affixing of CE marking following conformity assessment, the companion declaration to Article 47.
ICT-related incident reporting
Logging and traceability of ICT incidents, the hash chain makes the log itself auditable.
Accountability
Must be able to demonstrate compliance, the verification page is that demonstration, without trusting the database.
Reporting obligations
Incidents must be reported with traceable records, the chain proves records have not been altered post-incident.
Penalties for non-compliance
Article 99 sets fines up to €35M or 7% for deploying a prohibited practice, and up to €15M or 3% for breaching Articles 9–15, 47–48. GDPR Article 83 sets up to €20M or 4% for processing without appropriate technical measures. An unverifiable log or an unsigned declaration weakens the accountability defence in both regimes.
Frequently asked
Can a database admin tamper with the audit log without detection?
No, without also rewriting every subsequent hash. Each entry's current_hash covers the previous_hash, so changing one entry's details or deleting it causes verify_audit_chain to fail from that point forward and report the broken log ID. The check is deterministic and recomputed on demand, not based on a stored flag.
What if the signing key is rotated or lost?
Rotation does not invalidate old documents. Each DocumentSignature row stores its own public_key_pem and key_fingerprint at generation time, so verification of an old document never consults 'the current key.' History (last 10 fingerprints) is kept for the admin UI, but verification is per-document. A new key only signs new documents.
Do auditors need a EuroCompliant account to verify?
No. The public verification page at /verify/document/{verification_id} is unauthenticated. It shows signature validity, audit-chain status and key fingerprint in three steps, with no login. Share the verification URL that is embedded in the PDF footer and returned as the X-Verification-Url response header.
What is the difference between Ed25519 and PAdES?
Ed25519 is the hash-notarization path: a detached signature over the canonical document bytes, stored as DocumentSignature.signature_b64 and verified via the platform. PAdES is the in-PDF path: an embedded RSA-2048 X.509 signature visible in any PDF reader. Both are generated together on Enterprise; Ed25519 is used on all signed plans, PAdES only where a PDF certification is needed.
Does signing prove the content is legally correct?
No. It proves the bytes a regulator holds are exactly what the platform generated, on the date it claims, with the audit trail intact at that tip. It is an integrity and provenance guarantee, not a legal attestation. You remain responsible for reviewing what the document actually says.
Related guides
Evidence vault & audit trail
Turning completed checklist items into artefacts a regulator can inspect, and the logging duties behind Articles 12 and 26.
Documentation & evidence generation
Generating Annex IV technical documentation, declarations of conformity and framework records from data you have already entered.
Automated Scanning: Continuous Telemetry and Scan Pipelines
How scheduled scan jobs, 12 scan engines and local PII scrubbing produce dated Article 10/15 evidence without moving data outside the EEA.
Agent Runtime Telemetry
Stream signed execution decisions from your autonomous-agent runtime firewall straight into tamper-evident audit evidence.
Try it on your own systems
Everything in this guide runs in the live product. Start a free trial and follow along with your own data.
Start free trial