Security & Compliance

This section describes Quantra's security model: how users sign in and prove who they are, how the platform decides what they may do, how communication is encrypted, how sessions are managed, and what is recorded in the audit log. The intended audience is administrators, security reviewers, and developers.

Authentication

Quantra uses email-based authentication. The email address is the unique identifier for every account; there is no separate username. Passwords are stored and verified by the standard authentication framework, which hashes passwords using its built-in Password-Based Key Derivation Function 2 (PBKDF2) with a Secure Hash Algorithm 256 (SHA-256) hash and a random per-password salt. Plain-text passwords are never stored.

Sign-In Flow

1. The user submits their email address and password to the /login/ view.
2. The platform validates the credentials against the CustomUser table.
3. If the user has a Time-based One-Time Password (TOTP) device enrolled, or if Multi-Factor Authentication (MFA) is platform-enforced, the user is redirected to the MFA verification page before the session is fully established.
4. On successful verification, a server-side session is created and a session cookie is issued. If the splash page is enabled, the user is shown the splash page before reaching their dashboard.
5. On failure, the failed-attempt counter for the requesting Internet Protocol (IP) address is incremented; once it exceeds the configured threshold the address is locked out (see Rate Limiting below).

Multi-Factor Authentication

Multi-Factor Authentication (MFA) is implemented on top of the django-otp library. Two device types are used:

• TOTPDevice — the primary MFA device, using the Time-based One-Time Password (TOTP) algorithm defined in Request for Comments (RFC) 6238. The shared secret is stored on the TOTPDevice row, not on the user record.
• StaticDevice with StaticToken children — the recovery-code device. Each token is an 8-character hexadecimal string. Tokens are single-use and are deleted from the database the moment they are consumed.

Enrolment

When a user enrols, the platform generates a TOTP secret and renders a Quick Response (QR) code that encodes the standard otpauth:// provisioning Uniform Resource Identifier (URI) — including the issuer name "Quantra", the user's email address, and the algorithm parameters. The user scans the QR code with any compatible authenticator (Google Authenticator, Microsoft Authenticator, Authy, 1Password, and so on). The raw secret is also displayed for manual entry.

Recovery tokens are generated and shown to the user once at enrolment. The user must save them somewhere safe; they are the only way back into an account whose authenticator app has been lost.

Platform-Wide MFA Mode

The SystemSettings singleton exposes a mfa_mode field (an enum, not a boolean) with three values:

• enforced — every user must enrol an MFA device before they can use the platform. Users without an enrolled TOTPDevice are forced through enrolment on next sign-in. This is the default.
• optional — users may enrol from their account settings if they wish.
• disabled — the MFA flow is bypassed entirely.

Enforcement is done by middleware that intercepts every request and redirects users without an enrolled device to the enrolment flow when the mode is enforced.

Authorization

Access to a project is controlled by the ProjectShare model. Each row records a project, the user it has been shared with, the permission level, and the user who granted the share. The owner of a project (the owner foreign key on Project) implicitly has Write-level access; no ProjectShare row is needed for the owner.

Permission Levels

Level	Stored value	Capabilities
Read	read	Open the project, browse the canvas and its execution history, and review the audit log. Cannot run the pipeline or modify the canvas.
Execute	execute	Everything Read can do, plus running the pipeline and triggering scheduled runs.
Write	write	Everything Execute can do, plus adding, modifying, or removing nodes and edges and changing node configuration. Cannot delete the project or change its sharing — those remain owner-only actions.

The ProjectShare model exposes can_read(), can_execute(), and can_write() helper methods that views use to gate every project-scoped action. Permission checks always apply: a user with no ProjectShare row and no ownership cannot see a project at all.

Transport Security

All communication between the platform and its microservices goes over Google Remote Procedure Call (gRPC) with mutual Transport Layer Security (mTLS). In mTLS, both sides present X.509 certificates and verify each other's identity. This prevents an unauthorised process from connecting to the microservice mesh and protects every byte exchanged between the platform and its services.

Certificate Files

Certificates live on the filesystem at /home/einar/quantra/ms/certs/. The directory should be readable only by the platform service account, and the private keys must not be world-readable.

File	Role
ca.crt	The Certificate Authority (CA) root certificate trusted by every component in the mesh.
ca.key	The CA private key. Required only on the host that issues new certificates.
server.crt	Server certificate presented by each microservice and by the platform's gRPC services.
server.key	Server private key paired with server.crt.
server.csr	Certificate signing request used the last time server.crt was issued.

The deployment uses a single shared server certificate trusted by every party rather than separate per-service or per-side certificates. There are no separate client certificates checked into the active certificate directory; the same server.crt/server.key pair is presented in both directions of every connection. (An older two-sided certificate set is still on disk under ms/oldCerts/; it is no longer in use.)

Microservice Command-Line Arguments

Every microservice accepts the same set of command-line arguments for binding and TLS:

Argument	Description
--listen <address>	The address (host and port) the microservice listens on.
--use-tls	Switch the listener into mTLS mode. Without this flag the microservice runs in plain text — intended only for local development.
--server-cert <path>	Path to the server certificate.
--server-key <path>	Path to the server private key.
--ca-cert <path>	Path to the Certificate Authority certificate that the microservice uses to validate connecting clients.

The qm script that starts the microservices passes these arguments (and the --use-tls flag, when invoked with qm start --tls) to every service in the deployment.

Web Application Transport

The web application is served over HyperText Transfer Protocol Secure (HTTPS) on port 4443 by runsslserver. For deployments behind a reverse proxy that terminates TLS, the platform honours SECURE_PROXY_SSL_HEADER in settings.py so that it correctly identifies the original request as HTTPS.

Session Management

Sessions are server-side; only the session identifier is stored in a cookie on the client. The session backend is the standard one used by the underlying web framework.

• SESSION_COOKIE_HTTPONLY = True — the session cookie is not accessible to JavaScript. This protects the cookie from cross-site scripting attacks.
• SESSION_COOKIE_SECURE = not DEBUG — in production (where DEBUG is false), the cookie is only sent over HTTPS.
• SESSION_COOKIE_AGE = 28800 — eight hours. This is the maximum lifetime, independent of activity.

Configurable Inactivity Timeout

A custom session-timeout middleware (session_timeout_middleware.py) reads the session_timeout_value and session_timeout_unit fields from SystemSettings on every request and calls request.session.set_expiry() with the result. This gives administrators a single platform-wide inactivity timeout that they can configure through the administration site without changing any code.

Sign-Out

The /logout/ view records an audit entry, then calls logout(request), which invalidates the session on the server and clears the cookie on the client. After logout, the cookie value is no longer associated with any session row, so capturing the cookie cannot be used to resume the session.

Rate Limiting

The platform implements two custom rate limiters. There is no use of django-axes, django-ratelimit, or any other third-party rate-limiting package — the logic lives inside the relevant views.

Login Lockout (per Internet Protocol address)

The /login/ view tracks failed sign-in attempts in the cache, keyed by the requesting IP address. Two settings on SystemSettings control the behaviour:

• login_max_attempts (default 5) — how many failures are tolerated before the address is locked out.
• login_lockout_minutes (default 15) — how long the lockout lasts.

Failed attempts are also written to the audit log so that administrators can see a pattern of attempts in advance of an actual lockout. A successful sign-in clears the counter for the address.

MFA Lockout (per user)

The MFA verification view tracks failed code submissions on the user's session. The mfa_max_attempts field on SystemSettings controls the threshold (default 5). Once the threshold is exceeded, the user is signed out immediately and must start the sign-in flow over.

The two limiters target different abuse patterns: the per-IP login limit slows down credential-stuffing or password-spraying attempts, while the per-session MFA limit prevents an attacker who has the password from grinding through TOTP codes inside a single sign-in attempt.

Cross-Site Request Forgery Protection

The platform's middleware stack includes the standard Cross-Site Request Forgery (CSRF) middleware. Every state-changing request from the browser must include the CSRF token issued by the server; requests without a valid token are rejected. Trusted cross-origin sources (for example, an upstream reverse proxy) can be added through CSRF_TRUSTED_ORIGINS in settings.py.

Splash Page and Banner Sanitisation

Administrators can enable a splash page that appears once per session after sign-in. This is commonly used for legal notices, environment markers (for example, "Production"), or compliance acknowledgements. The HyperText Markup Language (HTML) supplied for the splash page is sanitised by the platform: <script> tags, <iframe> tags, and inline event-handler attributes are stripped before the page is rendered, so a misconfigured banner cannot become a foothold for client-side attack code.

Audit Logging

Every security-relevant and project-relevant event is recorded on the AuditLog model. Each row stores the user, the event, a timestamp, the requesting Internet Protocol (IP) address, the project (if any), an outcome status, and a small set of event-specific fields (such as objects_processed, pii_detected, execution_time, and compliance_flags) used by execution and release events. There is no opaque catch-all metadata column — the schema uses real columns instead.

The platform records exactly nine event types; a full description of each event and how administrators view the log is in the Administration appendix. The events are: login, logout, login_failed, project_create, project_delete, project_share, project_unshare, execution, and release.

Audit log entries are exposed in two places: the system-wide list in the administration site at /admin/quantra/auditlog/, and the per-project view available from the project canvas (the Audit logs button on the left toolbar). There is no public read Application Programming Interface (API) for the audit log; this is intentional — access to the log is administrator-only or owner/share-only by design.

Data Protection Considerations

Quantra processes documents that may contain sensitive information. The platform is built around the assumption that an organisation deploys it in an environment it controls, so that document content does not leave the organisation's perimeter unless an explicit datasource (such as Box or SharePoint) chooses to bring it in. Inside that perimeter, several mechanisms help organisations meet their data-protection obligations:

• On-premises and private-cloud deployment. Quantra runs as a self-hosted application; document data does not need to leave the deployment boundary.
• Personally Identifiable Information (PII) detection and redaction. The PII Detect tool, the Review (Q-DACT) tool, and the SAR Release tool together provide a workflow for finding, reviewing, and applying redactions. See Tools.
• Project-level access control. The three permission levels described above ensure that only users with an explicit grant can access a project, its canvas, its results, or its audit log.
• Project isolation. Each project is its own canvas, execution history, and audit log; there is no implicit cross-project data sharing.
• Document lifecycle. Deleting a project removes the canvas, the execution history, and the schedules. Source files held inside an upstream system are not deleted by Quantra.
• Subject Access Request (SAR) workbenches. Q-SAR and Q-NHS-SAR provide a defensible review workflow for SARs under the General Data Protection Regulation (GDPR). See Workbenches.
• Record of Processing Activities (RoPA). Q-RoPA maintains the GDPR Article 30 register of processing activities. See Workbenches.

Compliance

Quantra's security features are designed to give an organisation the building blocks it needs to meet a range of regulatory and industry frameworks. The platform itself is not certified against any specific standard, but the features described above — strong authentication with enforceable Multi-Factor Authentication, role-based access control with three permission levels, transport encryption with mutual Transport Layer Security, configurable inactivity timeouts, brute-force and code-grinding rate limits, an immutable audit log, and a structured approach to PII review and redaction — correspond to common requirements in frameworks such as International Organization for Standardization (ISO) 27001, Service Organization Control (SOC) 2, and GDPR.