Security and architecture

Every application ComplianTech builds is designed to answer four questions before it accepts a single piece of data: Is this device trusted? Is this person who they claim to be? Are they allowed to do this? And has it been recorded?

This page describes the architecture of the applications ComplianTech builds for clients. It doesn’t describe this marketing website. It is written for Quality and IT alike, with the overview first, followed by the Part 11 mapping and the technical detail.

Four checks on every transaction: the device, the person, the permission and the record. If any check fails, the data isn’t accepted.

Trusted devices

Instruments, data capture appliances and client applications can only send data to a ComplianTech application if they hold a certificate issued specifically to them. A device without one is turned away, no matter what network it’s on.

Device certificate chain of trust A root certificate authority signs an issuing certificate authority, whose keys are held as distributed fragments. The issuing authority issues a unique certificate to each authorized device: a capture appliance, a data capture client and an integration service. Each device's certificate is verified on every connection to the data services. An unknown device without a valid certificate is rejected. Root certificate authority Highest level of protection signs Issuing authority Key held as separate fragments issues Device certificate Unique to each authorized device issued to Capture appliance Data capture client Integration service Unknown device No valid certificate Verified on every connection Rejected Data services Accept data only from verified devices
Each certificate traces back to a protected root of trust. The signing key behind the issuing authority is never assembled in one place, so it can’t be copied or exposed by any single party.

Trusted people

Every person signs in through a central identity service, so each action is tied to a unique individual. The application then checks their role before allowing anything, and records what they did.

Identity and access flow A user with a unique account signs in through an identity provider offering single sign-on and multi-factor authentication, which can optionally connect to the organization's corporate directory. The application receives a signed identity token, and role-based access checks permissions on the server before every protected action. Sign-ins, failed attempts, permission changes and record actions all feed the audit trail. Corporate directory Optional connection User Unique personal account Identity provider Single sign-on, multi-factor Application Receives signed identity token Role-based access Checked before every action Audit trail: sign-ins, failed attempts, permission changes and every record action

What this means in practice

Only authorized devices

Data can’t be sent from an unapproved instrument, laptop or script, even inside your network.

Every person identified

No shared accounts. Every result, change and signature is attributable to one individual.

Only what the role allows

Analysts, reviewers and administrators each see and do only what their role requires.

Everything recorded

Security events and record changes are captured in an audit trail that users can’t alter.

How it maps to 21 CFR Part 11

The same architecture addresses specific Part 11 controls. Your validation of any system remains your responsibility, and we provide the documentation to support it.

RequirementWhat it asks forHow our architecture addresses it
11.10(d) Limiting system access to authorized individuals Unique accounts through central sign-on, with role-based access in every application
11.10(e) Secure, computer-generated, time-stamped audit trails Audit trails of security events and record actions that users can’t modify
11.10(g) Authority checks before using the system, signing or altering records Server-side role checks before every protected action
11.10(h) Device checks to determine the validity of the source of data input A unique certificate on every data capture device, verified on every connection
11.200(a) Electronic signatures using at least two distinct identification components Signing requires re-entry of credentials, linked to the authenticated identity
11.300 Controls for identification codes and passwords Central account management, multi-factor authentication and controlled account removal

Technical detail

For IT and security reviewers. Specific technologies and providers are disclosed during vendor qualification.

Device trust

A private public-key infrastructure (PKI) issues a unique certificate to each authorized device, appliance and client application. Connections use mutual TLS, so both sides prove their identity before any data moves. Certificates are issued and renewed automatically using industry-standard protocols, and revoking a certificate removes that device’s access.

Key protection

Certificate signing keys are managed with distributed key fragment cryptography. The fragments are held separately and the complete key is never assembled or exposed, giving zero visibility to any single party, including the key management provider. The design follows zero-trust principles: no device or user is trusted because of its network location, and every connection is authenticated.

Identity and authentication

Users authenticate through a dedicated identity provider using OpenID Connect, with single sign-on across applications and multi-factor authentication. The identity provider can connect to your corporate directory, so accounts follow your existing joiner, mover and leaver processes.

Authorization

Every application enforces role-based authorization on the server, using the authorization framework built into the platform rather than custom security code. Roles follow the principle of least privilege, and changes to role assignments are recorded in the audit trail.

Hosting and deployment

Applications are built on .NET and SQL Server and deployed as containers, either in the cloud or on your own infrastructure. All traffic is encrypted in transit. Containerized deployment means each release is a fixed, versioned build, which supports consistent qualification across development, test and production environments.

Under evaluation: biometric signatures

Part 11 includes specific provisions for electronic signatures based on biometrics. We’re researching how biometric authentication could make signing faster without weakening controls. It isn’t part of our systems today, and we’ll only introduce it once it meets the same standard as everything else on this page.

Support for your vendor qualification

We expect to be qualified as a supplier, and we make it straightforward. Under NDA, we provide:

  • Architecture and data flow documentation
  • Disclosure of the technologies and third-party services we use
  • Completed security questionnaires
  • Participation in supplier audits

Need architecture documentation for a review?

Tell us what your Quality or IT team needs, and we’ll provide it under NDA.

Contact us