Trust Center
Security whitepaper: the pilot, its controls and its open findings
Version 0.2.0, September 30, 2026. Written from the developer’s own review. It is not an audit, a certification or an independent assessment.
1. Scope and honesty
This paper covers the synthetic-data pilot hub and its clients. It does not cover a production deployment, because none exists. The review behind it was performed by the developer, not by an outside party. There has been no penetration test, no fuzzing campaign, no dependency vulnerability scan and no review of the cloud account configuration. Its own conclusion is that the pilot is safe to demonstrate with synthetic data and must not hold real patient data until the findings in section 4 are addressed and an independent review is done.
2. Design model
Access is deny by default and derives from the role roster (1,650 roles in tiers T0 to T9 and TS), care-relationship scope and, in the design, purpose and consent. Privileged actions need a second person. Audit is designed to be tamper-evident. The larger design (on-site servers, a ledger of hashes, key hierarchy, read limiter) is described in the architecture deep-dive and is not built.
3. Controls in the pilot
| Area | Control | Status |
|---|---|---|
| Authentication | Passwords of at least 12 characters (14 in the Hospital preset), forced change at first sign-in, one-time temporary passwords, TOTP MFA with recovery codes (on by default for the privileged tiers T7 to T9), replay protection, lockout after 5 failures with a security alert, generic errors, idle and manual lock, session list and revoke | In the pilot (v0.2.0, synthetic data) |
| Authorisation | Deny-by-default tiers, care-team scope, tenant isolation tests, two-person approval for privileged user changes, sysadmin roles without chart access | In the pilot (v0.2.0, synthetic data) |
| Cryptography | HTTPS and secure WebSockets; field-level AES-GCM for national IDs, MFA secrets and registration history; sessions stored as hashes | In the pilot (v0.2.0, synthetic data) |
| Application security | Security headers and CSP on API and static pages, CORS allow-list, parameterised SQL and no raw-markup APIs (both unit-tested), Electron sandbox with three IPC channels | In the pilot (v0.2.0, synthetic data) |
| Configuration integrity | Signed manifests, locked safety floors re-applied at run time, tamper detection on packages, dual-operator publishing | In the pilot (v0.2.0, synthetic data) |
| Audit and emergency access | Hash-chained audit with verify; break-glass with reason, time box, alert and mandatory review | In the pilot (v0.2.0, synthetic data) |
4. Open findings
Severity labels are the review’s own.
| Ref | Severity | Finding | What closing it needs | Status |
|---|---|---|---|---|
| F2 | Medium | The demo vendor signing private key is in the demo code base, and the demo hub trusts its public half. | A production key custody model (hardware-backed, split custody) and rotation. Custody is undecided. | Open decision |
| F3 | Medium | Passwords are hashed with PBKDF2-SHA256 at 100,000 iterations rather than Argon2id, and there is no breached-password check. | A move to Argon2id (the specification asks for 64 MiB memory and t≥3 or an equivalent) and a breached-password screen. | Open decision |
| F4 | Medium | The field-encryption key is a real hub secret, but there is no rotation, no per-tenant key and no key management service. A local default is insecure. | The key hierarchy in the design, with per-tenant keys and scheduled rotation. | Open decision |
| F8 | Low | Privacy compartments are flags plus an attested purpose, not a legal consent engine. | A consent module and privacy operations, with local legal review. | Open decision |
| F11 | Info | The audit chain is tamper-evident but not write-once, and has no external anchor. The database owner could rewrite the chain and its head. | Append-only storage and anchoring, as in the design. | Open decision |
| F12 | Info | There is no per-IP rate limit; only per-user limits and account lockout. | Edge rate limiting and abuse controls. | Open decision |
Other items were accepted for the pilot: the break-glass lookup reveals that a restricted record exists (audited, role-limited); CORS allows any localhost origin; bearer tokens live in session storage; a hosting analytics beacon is blocked by the CSP; login timing was not tested statistically. Static-page headers (F1) were missing and are fixed.
5. Verification evidence
Run by the developer on September 30, 2026, on synthetic data, and listed here without being combined into one figure: 90 of 90 unit checks; end-to-end suites of 108, 201 and 51 checks locally and on the live hub; a 37-step click-through; a scan of 122 screens with no problems; and a 34-check security probe that passed after the two real problems its first run found were fixed. These are internal tests. They are not an audit and do not show suitability for real patient data.
6. Designed controls
On-site closed servers; a federated ledger that holds only hashes, consent records and audit events; a key hierarchy with HSM custody; a read-side limiter, safe-degrade sync and a scroll-rate lock; sealed terminals; three-stream server-to-server transfer with hybrid post-quantum key exchange; keystroke-cadence analytics as a review flag only; crypto-shredding for deletion. All are Designed. Several parameters are open decisions, and hardware effectiveness is untested.
7. Not done
- No independent penetration test or code review; scope and provider are undecided.
- No certification, attestation or compliance claim of any kind.
- No production key management, no backups, no disaster-recovery drill, no monitoring programme.
- No operating-system or cloud-account hardening review.
8. Reporting a vulnerability
Email [email protected]. See security.txt. There is no bounty programme. The pilot holds only synthetic data.
Send us your security questionnaire
We will answer plainly, including “not yet”.