Security overview

§1. Overview

Witnium operates a cryptographic witnessing platform designed for high-stakes use cases including regulatory compliance under the EU AI Act. Security is foundational to the Service, not a feature layered on top.

This page summarises our security practices. It is supplemented by the Privacy Policy, the Data Processing Agreement, and the technical documentation at docs.witniumchain.com.

§2. Our security philosophy: independent by architecture

The most important security property of Witniumchain is that Witnium itself cannot access the content our Customers witness, cannot hold Customer private keys, and cannot alter records sealed on the chain.

This is not a policy commitment. It is a structural property of the SDK and the protocol.

• Owner keypairs are generated on the Customer’s client using Ed25519. The private key never reaches Witnium’s servers.
• Witness content is hashed (SHA-256) on the Customer’s client. Only the 32-byte fingerprint reaches Witnium.
• Signatures are produced locally on the Customer’s client using the Customer’s keys. Witnium receives signatures as opaque bytes for verification.
• Records sealed on the chain are tamper-evident. Modification would require coordinated attack against the consensus network, would be detectable, and would not be unilaterally feasible by Witnium.

The operational metadata Witnium does retain (timestamps, public keys, fingerprints, witness counts) is required for credit accounting and chain integrity. It contains no content and cannot be reverse-engineered into content.

§3. Infrastructure security

3.1 Hosting

The Platform is hosted on infrastructure located within the European Union or the European Economic Area. We select data centres certified to ISO 27001 and SOC 2 standards. Production environments are physically and logically segregated from development, staging, and corporate environments.

3.2 Chain layer

The Witniumchain chain runs on Hyperledger Besu with QBFT consensus, operated across geographically distributed validator nodes within the EU. The consensus algorithm is Byzantine-fault-tolerant; the chain remains live and correct as long as more than two-thirds of validators are honest.

3.3 High availability

Critical components are deployed across multiple availability zones with automated failover. We maintain documented and tested business continuity and disaster recovery procedures.

§4. Data protection

4.1 In transit

All connections to the Platform use TLS 1.3 or higher with modern cipher suites. HTTP Strict Transport Security (HSTS) is enforced. Older TLS versions are not supported.

4.2 At rest

Data at rest is encrypted using AES-256 with keys managed in a dedicated key management service. Database backups are encrypted using the same standard. Encryption keys are rotated periodically.

4.3 Architectural minimisation

As described in Section 2, the architecture of the Platform structurally minimises the Personal Data and content data we hold. This reduces both the attack surface and the impact of any incident.

§5. Access control and authentication

5.1 Customer authentication

Customers authenticate to the Platform using a combination of:

• email and password (passwords hashed using a memory-hard hash function with per-user salt);
• TOTP-based multi-factor authentication (optional but strongly recommended);
• OAuth 2.1 with PKCE for browser-based flows;
• organisation API keys for backend integrations, never displayed in plaintext after creation;
• signed-request authentication using Ed25519 for machine-to-machine integrations.

Sessions are tied to a server-side state with rotation on privilege elevation, configurable lifetime, and explicit revocation by the Customer.

5.2 Internal access

Witnium personnel access production systems only through individually attributed accounts with mandatory hardware-key multi-factor authentication, audited via central identity provider. Access follows the principle of least privilege, with privileged actions logged and reviewed.

5.3 Key management

Cryptographic keys used by Witnium-operated services (signing intermediaries, chain validator keys, infrastructure secrets) are stored in dedicated key management services with separation of duties between key custodians and operational personnel.

Customer private keys are not stored by Witnium; they exist only on the Customer’s systems.

§6. Cryptographic foundations

The Platform relies on the following cryptographic primitives:

• Hashing: SHA-256 for content fingerprints; SHA-3 family for selected internal uses.
• Signing: Ed25519 (Edwards-curve digital signature algorithm) for all customer signing operations.
• Symmetric encryption: AES-256-GCM for data at rest and selected in-transit channels.
• Key derivation: HKDF for derived keys; Argon2id for password hashing.
• Transport: TLS 1.3.

Cryptographic libraries used are open-source, audited, and updated promptly when vulnerabilities are disclosed. We do not implement custom cryptography for production use.

§7. Network security

• Web application firewalls in front of public endpoints, with rules tuned to the API surface.
• Distributed denial of service mitigation at edge and origin layers.
• Network segmentation between application tiers; databases are not accessible from public networks.
• Internal traffic between services authenticated and encrypted (mutual TLS where applicable).
• Continuous network monitoring with anomaly detection.

§8. Application security

8.1 Secure development

Our development practices include:

• mandatory code review by a second engineer for all production changes;
• automated static analysis on every commit;
• automated dependency scanning with prompt remediation of high-severity vulnerabilities;
• secret scanning to prevent credentials from being committed to source control;
• protected branches with required checks before merge to production.

8.2 Penetration testing

We are establishing an independent third-party penetration testing program covering the Platform’s externally exposed interfaces and the authenticated dashboard. The first independent test is scheduled to commence in 2026, and thereafter on an annual cadence at minimum, with additional tests following material architectural changes. Findings are tracked to closure with defined SLAs by severity. Customers on the Business and Enterprise plans may request a summary report under non-disclosure once the first test has been completed.

8.3 Bug bounty / responsible disclosure

We welcome reports of suspected vulnerabilities. See Section 16.

§9. Monitoring and logging

We maintain comprehensive logging of:

• authentication events;
• access to production systems;
• API requests to the Platform;
• administrative actions;
• security-relevant events from infrastructure components.

Logs are forwarded to a centralised security information and event management (SIEM) system, retained for a minimum of 12 months, and reviewed both by automated rules and by on-call security personnel.

§10. Incident response

We maintain a documented incident response plan covering preparation, identification, containment, eradication, recovery, and post-incident review.

On-call coverage is staffed 24/7 by engineers trained in our incident response procedures. Security incidents are escalated to senior management on an SLA basis defined by severity.

In the event of a Personal Data Breach, we will notify affected Customers within 72 hours of becoming aware, in accordance with our Data Processing Agreement and Article 33 GDPR.

§11. Vulnerability management

• Patch management on a defined cadence with emergency patching procedures for high-severity vulnerabilities.
• Automated vulnerability scanning of containers, virtual machines, and dependencies.
• A documented vulnerability disclosure process (see Section 16).

§12. Business continuity

• Documented business continuity plan covering personnel, infrastructure, and supplier disruption scenarios.
• Disaster recovery procedures tested at least annually.
• Recovery point objective (RPO) and recovery time objective (RTO) defined by service tier; documented in customer contracts where applicable.

§13. Personnel security

• Background checks where permitted by applicable law and proportionate to role.
• Confidentiality undertakings as part of employment and contractor agreements.
• Security awareness training on hire and at least annually thereafter.
• Defined onboarding and offboarding procedures, including timely access revocation.

§14. Vendor security

• Due diligence on Sub-processors before engagement, including review of security posture, certifications, and data protection terms.
• Contractual data protection terms with all Sub-processors, including DPA terms back-to-back with this Service.
• Periodic review of Sub-processors during the engagement.

The current list of Sub-processors is at witniumchain.com/subprocessors.

§15. Compliance and certifications

We pursue compliance through architecture first and external frameworks second. The architectural separation described in Section 2 is, in our view, a stronger control against most realistic threats than any certification would provide on its own. We are nevertheless committed to formal frameworks as the company matures.

• GDPR compliance program, including the Data Processing Agreement made available to all Customers.
• EU AI Act readiness program. Witniumchain is itself the audit infrastructure that customers use to meet certain obligations under the Act, in particular Article 12 logging requirements.
• Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) for cross-border transfers of Personal Data, where applicable.
• We do not currently hold ISO 27001 or SOC 2 certification. We will pursue certification on a timeline appropriate to the Service’s customer base; in the interim, we provide detailed security documentation and respond to Customer security questionnaires on request.

§16. Responsible disclosure

We are committed to working with the security community to identify and address vulnerabilities. If you believe you have identified a vulnerability in the Services:

• Email security@witnium.com with a description of the vulnerability and reproduction steps. For sensitive reports, request a secure channel in your initial message and we will provide one.
• Allow us a reasonable period to remediate before public disclosure.
• Do not exfiltrate Customer data or impact Service availability during testing.

We acknowledge receipt of reports within 3 business days and aim to provide an initial assessment within 10 business days. We do not currently operate a paid bug bounty programme, but we recognise material contributions to Witnium’s security publicly (with the reporter’s permission).

§17. Contact

For security questions or to report a vulnerability, email security@witnium.com.

For privacy questions, see the Privacy Policy.

For other enquiries, email hello@witnium.com.

---

Witnium Technologies AB · All documents version 1.0, effective 25 May 2026