System Changelog

The v1.0.0 entry described itself as the first validated release and the qualified baseline. No release has been validated yet, so v1.0.0 is restated as the pre-validation development baseline, and the v1.0.1 and v1.0.2 entries no longer refer to "validated" functions. The validated baseline will be the first release whose IQ/OQ/PQ package is approved.

Changelog entries v1.0.0 to v1.0.4 are reworded so that they describe services generically (for example, "Key Management Service" rather than the provider's product name), and internal infrastructure identifiers are removed. Named software dependencies remain where a change record has to identify the patched package.

v1.1.0 is GxPSign's first production release. It brings together everything built through the v1.0.x pre-release series, plus hardening from a customer security review. What it provides:

Electronic signatures (21 CFR Part 11, EU GMP Annex 11)

• Re-authentication at every signature, with no session window that skips it: a passkey (WebAuthn with user verification required, and sign-counter clone detection), the account password, or an SSO step-up that forces a fresh sign-in at the identity provider.
• An organization policy that requires a passkey for every signature.
• Each signature records its meaning (for example Approved or Reviewed). The signature block on the PDF shows the signer's name, the meaning and the date and time.
• Completed PDFs are sealed with a PAdES digital signature. The platform signing key is generated inside a Key Management Service and cannot be exported; the application can only ask the KMS to sign. The self-signed certificate is embedded in every signed PDF and is limited to document signing.
• A Certificate of Completion is issued once every signer has signed. Signed PDFs can be checked on the in-app verification page.

Documents and signature workflows

• PDF upload with a SHA-256 hash recorded at upload, an in-browser viewer, drag-and-drop field placement and reusable templates.
• Multiple signers per request. External signers sign through a secure single-use link. Every signer has an inbox covering requests from any organization.
• Once a request is sent, it can no longer be deleted and its fields can no longer be changed.
• Document retention with scheduled purging.

Audit trail

• Records sign-in, sign-out, failed sign-in, session timeout, re-authentication, document upload and view, each signature, and settings changes (with old and new values). Each entry carries the user, a UTC server timestamp, the real client IP address and the user agent.
• The audit tables are append-only in the database itself: it refuses updates, and it refuses deletion except for retention purges of entries older than 30 days.
• Changes made by platform administrators are recorded and shown to the affected organization.
• A request's audit trail can be exported as CSV.

Access control and tenant isolation

• Email sign-in with verified addresses, 12-character minimum passwords with complexity rules, and passwordless passkey sign-in.
• Per-organization OIDC or SAML single sign-on, optionally enforced. Accounts kept on a local password are listed for access review.
• Organization roles (Owner, Admin, User) and SignatureManager seats for sending requests.
• A per-organization inactivity timeout, 30 minutes by default.
• Organizations are isolated by database row-level security, enforced in the database rather than in application code.

Platform security and operations

• All traffic passes through a CDN proxy and web application firewall, over TLS 1.2 or higher with HSTS preload.
• A Content-Security-Policy, with every script served from GxPSign's own origin.
• The cross-tenant platform administration console requires a passkey sign-in.
• Vulnerability reports go to the contact published at /.well-known/security.txt.
• The test environment runs on its own server, separate from production.
• Nightly encrypted database backups are stored off-host. Documents and backups are kept in encrypted file storage.

The table lists the changes since v1.0.4.

Organizations are no longer addressed by subdomain. Every organization is served from one host per environment (gxpsign.app, test.gxpsign.app), and the signed-in user's organization is shown in the app navbar instead. The subdomain never granted access (RLS was already derived from the user's own organization), so the access model is unchanged; what goes is the subdomain redirect, the wildcard cookie/CSRF/CORS/WebAuthn allowances it needed, and the *.gxpsign.app / *.test.gxpsign.app routing.

The platform PDF signing key moves into a Key Management Service (KMS). The key is generated in the KMS as a non-exportable RSA key at software protection level (FIPS 140-3 Level 1); GxPSign sends a SHA digest and receives the signature back. HSM protection (FIPS 140-3 Level 3) is not yet offered in the region used; when it is, the key will be rotated to HSM by issuing a new platform certificate. The application no longer stores or loads a private key: the PlatformCertificate.private_key_pem and private_key_password columns are dropped, closing the gap against URS-SEC-03 ("Private keys shall not be stored in plaintext in production") — the key was previously held in plaintext in the database and therefore in every backup.

Remediation of the GxPSign findings from the 2026-10-02 internal security review. Two findings were rated High and both defeated tenant isolation on the signing path: a self-service email change let any account claim another person's pending signature requests in every tenant, and a tenant-configured identity provider could assert an arbitrary address and be logged in as that person's existing account. The rest tighten deletion and field-edit guards on sent requests, close a stored-XSS vector in the signer list, align the purge window with the documented retention period, keep secrets out of the image build context, and clear every published advisory from the runtime dependency set.

Classified High because the changes touch core GxP workflows: who may sign, who may be provisioned into an organisation, what may be deleted, and how long the audit trail is retained.

Removes the last latest image-tag fallback from the deployment compose template. The live production compose and the release workflow were corrected in v1.0.0; this template carried the same construct under a different variable name and was missed. No application code changes — the running system is functionally identical to v1.0.0.

First versioned release of GxPSign and the development baseline for this changelog. It describes the system as it stood rather than a change to it. It is not a validated or qualified release: no IQ/OQ/PQ was executed against it. Development history before this release remains in the repository's git history but is not recorded here.

The baseline covers PDF e-signature workflows with 21 CFR Part 11 aligned signature manifestations, an append-only signature audit trail, database row-level security for tenant isolation, OIDC/SAML single sign-on with re-authentication at signing, and the release pipeline that deploys it.