Configuring Sphinx for 21 CFR Part 11

Read this first. No software can make an organisation Part 11 compliant, and this document is not legal or regulatory advice. Part 11 governs your practices: your validation, your SOPs, your training records, your signature manifestations, and your certification to the FDA that electronic signatures are the legally binding equivalent of handwritten ones. Sphinx supplies technical controls that a compliant system needs; whether your use of it is compliant is a determination for your quality and regulatory functions. Treat everything below as an engineering checklist to hand to those people, not as a substitute for them.

1. What the software does, mapped to the regulation

Requirement	What Sphinx provides	What you must still do
§ 11.10(a) validation	Deterministic, inspectable behaviour; a hash-chained audit trail that makes silent change detectable.	Perform and document IQ/OQ/PQ against your own requirements. Software cannot validate itself.
§ 11.10(b) accurate copies	Content is content-addressed by SHA-256 and verified on every read; audit logs export as signed, timestamped PDF/A-2b.	Confirm the exported form is acceptable to your inspectors, and test that exports open and verify on your systems.
§ 11.10(c) record protection and retrieval	Every version retained; deletes are tombstones; time-travel reconstruction of any past state.	Back up Postgres and object storage, test restores, and set a retention period that meets your predicate rules.
§ 11.10(d) limited access	OIDC authentication; per-library and per-folder authorisation; global administration confers no access to any library's contents, structure, audit log or permissions, so an administrator must take a recorded grant before they can see anything. No anonymous access other than the public hash-chain publications, which contain no data.	Operate the identity provider to an equivalent standard, and review grants periodically.
§ 11.10(e) secure, time-stamped audit trails	Append-only per-library chain covering creates, modifications, deletions, permission changes, signatures and reads. Each entry commits to the whole prior history; the server refuses to record anything while its clock is unverified.	Leave read auditing enabled when creating libraries. Keep NTP reachable. Retain the log for the record retention period.
§ 11.10(f) operational sequencing	Archived libraries reject content changes and signatures; blacklisted content cannot be re-introduced silently.	Define your workflow states in SOPs; Sphinx does not model approval workflows for you.
§ 11.10(g) authority checks	Capability-based authorisation on every operation; management authority is separate from content access.	Document who may hold which role and why, and evidence periodic review.
§ 11.10(k) documentation controls	Versioning and audit history apply to the documents you store, including your SOPs if you store them here.	Control your own system documentation and revision history.
§ 11.50 signature manifestations	Each signature records the signer's printed name, the date and time, the meaning (Review, Approval, Authorship) and the exact SHA-256 of the signed version, all inside the audit chain and reproduced in exports.	Confirm the meanings offered match your process, and that they appear correctly on your printed outputs.
§ 11.70 signature/record linking	Signatures bind to a specific immutable version hash, not to a file name, so they cannot be transferred to different content.	Nothing further technically; cover it in your validation evidence.
§ 11.100(a) unique identity	Identity comes from the OIDC subject; grants key on verified email addresses.	Guarantee at the identity provider that identifiers are never reused or shared, and verify identity of individuals before issuing accounts.
§ 11.200(a) signature components	Every signature forces a fresh authentication at the identity provider (`prompt=login` with `max_age=0`), and the freshness is verified server-side before the signature is recorded.	Configure the IdP so that a fresh login means both components — user identification and password (and any additional factor). If the IdP silently re-authenticates by cookie, the control is defeated.
§ 11.300 identification code / password controls	Sphinx holds no passwords at all.	Entirely yours: password ageing, complexity, lockout, device token management, and periodic testing.

2. Required configuration

These are the settings that a compliant deployment is expected to have. Several are defaults, but they can be turned off, so verify each one on the running system.

Read auditing on for every library. It is the default; it is chosen at creation and can never be turned off afterwards, only on. If a library shows the reads not audited badge, it does not satisfy § 11.10(e) for access records.
Time verification enforced. Leave SPHINX_REQUIRE_TIME_SYNC at true so nothing is ever recorded while the clock is unverified, and make sure the NTP server is reachable from every instance.
Certificate identity that names you. Sphinx generates and maintains its own CA and annual signing certificates if you supply none, which is a supported configuration — but set SPHINX_CERT_SUBJECT so the certificate names your organisation, and record its root fingerprint in your validation documentation. Alternatively supply SPHINX_SIGNING_PFX_BASE64 from your own CA. Either way, publish the root fingerprint internally so a reviewer can check a document against it.
Timestamping reachable. Signing and RFC 3161 timestamping are both mandatory and cannot be disabled: a document that cannot be signed and timestamped is not produced. Confirm at least one authority in SPHINX_TSA_URLS is reachable from every instance, and for an isolated network, run one locally.
Banners monitored. A red banner means audit exports and daily hash-chain publications are not being produced. Nothing is lost while it persists — the chain keeps recording and deferred publications are produced later, stating why they were late — but the gap is visible to inspectors, so treat the banner as an incident.
Object-storage encryption understood and documented. The AES key encrypts what is written to object storage, on the assumption that Postgres is the trusted store and the bucket may not be. If SPHINX_AES_KEY is unset the key is generated and held in Postgres, which is consistent with that model — but keep database and object-storage backups separate, since combining them recombines what the split protects. Set SPHINX_AES_KEY from a secret manager if your risk assessment requires the key never to rest in the database.
HTTPS everywhere, with the reverse proxy forwarding X-Forwarded-Proto. This is enforced rather than recommended: the session cookie carries the __Host- prefix and is always marked Secure, so sign-in cannot work over plain HTTP. The same prefix requires Sphinx to be served from the root of its origin rather than under a path prefix.
Identity provider hardened: verified email addresses, given_name and family_name populated for every user (signatures are refused without a printed name), multi-factor authentication, and no shared accounts.
Administrators kept few and named. SPHINX_ADMIN_EMAILS is visible to all users by design; keep the list short and reviewed. Note that administration alone grants no sight of any library: administrators appear in a library's audit trail the moment they grant themselves access, which is exactly the evidence a reviewer wants.
Auditors given Audit only. It provides the audit log and the folder structure, live and historical, with no ability to open a file or alter anything — the appropriate role for an inspector or internal auditor reviewing the running system.
Quorum set deliberately. SPHINX_QUORUM governs permanent deletion and lifting a content blacklist. Two is the default; raise it if your procedures require it.

3. Operational practices Sphinx cannot enforce

Validation and change control for the deployment, including revalidation after upgrades.
Backup, restore testing and disaster recovery for Postgres and object storage.
Periodic access reviews, and prompt revocation when people change role or leave.
Training records showing that users understand what an electronic signature commits them to.
The § 11.100(c) certification to the FDA that your electronic signatures are legally binding equivalents of handwritten signatures.
Procedures holding individuals accountable for actions taken under their credentials.
A documented decision, with rationale, wherever you deviate from the configuration above.

4. Things worth knowing before an inspection

Reading the audit log is not itself audited. Viewing or exporting the log leaves no entry, by deliberate design: reading a record is not an action on it. Be ready to explain this; the absence of read-of-log entries is not a gap.
The audit trail records downloads from the server, and nothing more or less. A download is a transfer of bytes out of the server, and every one is recorded. The browser keeps files it has already downloaded in memory for the session so it does not download them again unnecessarily; that is a client optimisation and does not suppress anything the server would otherwise have recorded. The log is evidence of what the server released and to whom, not a count of how many times someone opened a document on their own machine — no server-side system can evidence the latter.
Blacklisted content is destroyed but never unrecorded. The file rows, versions and history remain; only the stored bytes are removed, and downloads return 410. Every affected library gets its own audit entry, including archived libraries — archiving freezes content changes, and removing compromised bytes is not a content change. An administrator can also blacklist a hash that no library currently holds, which destroys nothing and records nothing at the time, but refuses and records any later upload of those bytes.
Documents cannot be signed retroactively. Signing keys are destroyed once they can no longer sign anything new — annual leaf keys at the end of their year, CA keys once a successor takes over — so nobody, including the operator, can later produce a document that appears to have been signed in a past year. Certificates are retained forever so old documents stay verifiable.
What a document signature proves. That it came from this deployment's key, which is the appropriate claim for an attestation about the state of the record. It is not a claim that a named individual approved anything; that comes from the electronic signatures inside the record, which require the signer's credentials at the moment of signing.
Bulk actions are one event per item. They are grouped for readability under a single heading, but every item has its own event, payload and hash in the exported PDF.
Permanent library deletion really is permanent, including the audit chain, and needs a quorum of administrators. Published daily hash-chain PDFs survive it and still evidence that the library existed and what its chain head was.
Public daily publications anchor every chain head in a signed, timestamped document that anyone can fetch without logging in. They are the strongest evidence you have that history was not rewritten after the fact; keep them.

5. A minimal qualification checklist

Evidence worth capturing during OQ, all reproducible from the interface:

Upload a file; confirm the audit entry, hash and version number.
Upload a changed copy under the same name; confirm it becomes version 2 and version 1 is still retrievable.
Delete the file, upload it again at the same path, and confirm the history continues rather than restarting.
Sign a version; confirm re-authentication was demanded, and that the printed name, meaning, timestamp and hash appear in the log.
Attempt an action without permission; confirm refusal and that nothing was recorded as having happened.
Run Verify chain; confirm it passes. Then, in a test database only, alter one audit row directly and confirm verification fails and identifies the entry.
Export the audit log; verify the PDF signature and timestamp with your own tooling, and recompute a few chain hashes by hand from the printed canonical fields.
Compare the certificate fingerprints printed in an export against /public/certificates, and confirm the root fingerprint matches the one in your validation records.
Block outbound access to the timestamping authorities; confirm that audit exports are refused with an explanation, that the red banner appears, that uploads and signatures still work, and that the deferred daily publication is produced afterwards and states why it was late.
Use History to reconstruct the library at a past moment; confirm it matches what you know the state to have been.
Stop NTP or skew the clock; confirm the server refuses to record audited operations.

Sphinx is a technical control set, not a compliance certificate. The controls above are designed to make the evidence hard to falsify and easy to produce; the surrounding quality system is what makes it compliant.