Security Statement

1. The security model in one paragraph

2. Record integrity

Tamper-evident audit trail

Every create, update and delete appends an entry to a per-organisation SHA-256 hash chain, each entry carrying the hash of the one before it. Altering or removing a historical entry breaks every hash after it, which is detectable and cannot be repaired without the whole chain being visibly rewritten. Appends are serialised by a database advisory lock, so concurrent writes cannot produce a forked chain.

This runs on every tier, including Free, permanently. We do not sell a weaker guarantee about a laboratory’s own data. What the paid tiers add is the ability to verify and demonstrate the chain to an assessor — not the protection itself.

Electronic signatures

Finalising a notebook entry captures an electronic signature with password re-authentication, binding the act to an individual at a moment in time. Finalisation is one-way: a finalised entry cannot be returned to draft, and the update path refuses to write to one. Corrections are made by amendment, which leaves the original visible — the ALCOA+ expectation.

3. Access control

• Roles are per organisation — owner, administrator, member — not global. A person’s rights in one laboratory say nothing about their rights in another.
• Every query is scoped to the owning organisation. Cross-tenant reads are blocked at the data layer, and that is checked by an automated isolation suite run against a live database before release.
• Sessions are carried in HttpOnly, SameSite cookies signed with a deployment-specific secret. Archon refuses to start in production with a weak or placeholder secret rather than running insecurely.
• Server actions and API routes re-authorise on every call. Nothing relies on the UI having hidden a button.

4. Data protection

• Field-level encryption at rest using AES-256-GCM for sensitive fields, when an encryption key is configured.
• Strict Content Security Policy. connect-src permits the application’s own origin only, so a compromised or malicious script in the browser cannot exfiltrate laboratory data to a third-party host. Scripts, fonts and images are likewise same-origin.
• No outbound telemetry. Archon makes no call to us. Licences verify offline against a bundled public key, so an air-gapped deployment is fully functional.
• Outbound webhooks are constrained by an optional host allowlist and, by default, refuse to target private network addresses — so an integration cannot be turned into a probe of your internal network.
• The AI assistant is off by default. Cloud mode is reported as a failed control on the accreditation dashboard, so it cannot be enabled without the quality manager seeing it.

5. What remains yours

Archon is self-hosted, so the perimeter around it is yours. We cannot do these for you, and an assessor will ask about them:

• Server and operating system hardening and patching.
• TLS termination and certificate management.
• Database access control, network isolation and encryption at rest at the volume level.
• Backups, and testing that they restore. We hold no copy of your data and cannot recover it.
• Physical security of the server.
• Assigning roles to the right people, and removing them when someone leaves. Archon enforces the roles; only you know who should hold them.

Archon reports on several of these in its deployment readiness view, so gaps are visible before an assessment rather than during one.

6. How the software is built

• Type and lint errors fail the build. A green build means the code compiles — this was not always true, and the change was made after a runtime crash that a suppressed type error had allowed to ship.
• Automated verification suites cover licence verification, cross-tenant isolation, entitlement enforcement, query scoping and audit chain behaviour, and are run before release.
• Licences are Ed25519-signed tokens, deliberately not JWTs — there is no caller-supplied algorithm field to negotiate, which removes an entire family of signature-bypass bugs.

7. Reporting a vulnerability

We will not take legal action against anyone who reports in good faith, tests only against their own deployment, does not access, alter or destroy data belonging to others, and gives us a reasonable period to fix an issue before disclosing it publicly. We are happy to credit you when we publish the fix, unless you would rather we did not.

Please do not test against deployments you do not operate, and please do not run denial-of-service or spam testing. See our Acceptable Use Policy.

8. If something goes wrong

Where we become aware of a vulnerability affecting deployments in the field, we will publish a fix and notify licensed customers by email at the address on their licence record, with enough information to judge their own exposure. Because we hold no customer data, a breach of our systems cannot expose your records — but it could expose the limited billing data described in our Privacy Policy, and we would notify you of that within 72 hours.