metroliq
Security · identity · isolation · integrity

Security you can read, not a badge.

No SOC 2 or ISO 27001 certificate yet, and we will not pretend otherwise. What we have is a set of controls you can inspect: scrypt-hashed passwords, opaque sessions, TOTP two-factor, SSO with signature verification, SCIM provisioning, row-level tenant isolation with its own test suite, a hash-chained audit trail, signed webhooks, and nightly backups with a weekly restore test.

Everything on this page is taken from the code or the running system. Where a control does not exist, it says so.

Try it · architecture

Click a box.

How a request travels and what each layer enforces.

In the product

The controls, on screen

Security settings
SSO (OIDC, SAML), SCIM, two-factor policy, password expiry, idle logoff, access review.
Identity and access

Who can get in, and how

Passwords and sessions

  • Passwords hashed with scrypt (16-byte random salt, 32-byte key), compared in constant time
  • Opaque session tokens (48 hex characters of randomness) stored server-side; 12-hour sessions, 30 days with remember-me
  • Idle logoff per tenant policy; the session row is deleted on timeout
  • Account lockout after 5 failed attempts for 15 minutes (HTTP 423), audited
  • Password expiry per tenant policy with forced rotation at login (Part 11 §11.300(b))
  • Minimum password length 8. Not yet: password history, complexity classes

Two-factor

  • TOTP (RFC 6238, SHA-1, 6 digits, 30 s, ±1 step); secret stored only after a valid code
  • 8 single-use backup codes, SHA-256 hashed
  • Tenant policy can require 2FA: un-enrolled staff can reach nothing but the enrolment screens
  • Login challenge expires after 5 minutes

Single sign-on and provisioning

  • OIDC: discovery, RS256 only, signature checked against JWKS by key id, issuer/audience/expiry/not-before checked; just-in-time provisioning with group-to-role mapping
  • SAML 2.0: signed responses required and verified against the IdP certificate; conditions, audience and issuer checked; SP metadata published
  • SCIM 2.0 users endpoint with a per-tenant bearer token hashed at rest and shown once; deprovisioning deactivates, never deletes, so signatures survive
  • API keys with read or write scope, hashed at rest, last-use stamped

Authorization

  • Built-in roles admin, technician, approver, viewer; custom roles with a granular permission vocabulary
  • Module entitlements per plan (one free Beta 2 plan today, every module on)
  • Portal accounts can reach only portal routes, and every portal query filters by tenant and customer id
  • Platform operators use a separate login and session table; entering a tenant is an audited act
  • Access review: stale accounts (90 days), never-logged-in, privileged accounts, SSO and 2FA coverage
Record integrity

What makes the record trustworthy

Audit trail

  • SHA-256 hash chain: each entry hashes the previous hash plus a canonical serialisation (sorted keys, epoch timestamps) so database round-trips cannot break it
  • Appended in a transaction under a per-tenant advisory lock; collisions retried
  • Verify endpoint replays the chain and reports the first broken entry and why
  • Facets, CSV export and periodic review with an overdue flag

Signatures

  • Two components: identity plus password re-entered at signing; hash of user, record, meaning and time
  • Signing session configurable 0–480 minutes (default 30; 0 = password every time)
  • Editing a signed record rescinds its signatures, visibly and audited

Writes and deliveries

  • Idempotency-Key on writes, scoped per caller: in-flight → 409, reuse with a different route → 422, completed → replay with a header saying so; keys purged after 48 h
  • Webhooks signed with HMAC-SHA-256 (x-metroliq-signature), secret shown once; 3 attempts with backoff; delivery log
  • Outbound URL guard: http(s) only; loopback, link-local, metadata, RFC 1918 and unique-local addresses refused; names resolved and every address checked, at save and at send
  • Attachments capped at 12 MB, tied to a record the caller owns

Retention and recovery

  • Retention per record class (certificates, events, audit trail, CAPA, NCR, training 6 years; batch records 7; methods and documents 10), overridable; nothing auto-deletes
  • Legal holds, tenant- or record-scoped, with a reason; placement and release audited
  • Audited full-tenant export
  • Nightly backups of every database, copied to a second machine; 14 days local, 30 off-box; weekly automated restore test

Hardening

  • Helmet-based security headers on the API and a tuned content-security policy on the web app, so certificate and report iframes, PDF downloads and the customer portal keep working
  • Rate limiting on login, password reset and sign-up endpoints per IP and per tenant, HTTP 429 with a retry hint, hits recorded in the audit trail
  • Request-size limits tightened platform-wide with a scoped allowlist for routes that carry large files (imports, datasheets, attachments)
  • A headers-check endpoint reports the live hardening posture for compliance review

Trust, status and evidence

  • Public status endpoint with live component health (database, product library, instrument hub, model gateway, outbox, scheduler), 30-day uptime from minute samples and an incident log with timelines
  • Release notes carry a validation-impact rating and an OQ re-run flag, so validated customers see what each release changes before it lands
  • Trust evidence computed live from the running system, never typed: password and lockout policy, 2FA, session and e-signature timeouts, audit-chain verification, retention policies, SSO/SCIM state, webhook signing, backup regime, sub-processors, and certification status stated plainly
  • Downloadable vendor assessment pack (PDF and JSON): the evidence above, our supplier verification summary, DPA and sub-processor annex, backup and restore statement, vulnerability disclosure and release policy
  • Sandbox workspace cloned from production for UAT and OQ re-runs before a release reaches the live tenant; site- and customer-scoped roles; OAuth2 client-credentials tokens verifiable via JWKS

Security evidence

  • Automated OWASP ZAP baseline and API scans plus npm audit across all services, repeatable by script; results feed the trust evidence API and the downloadable vendor assessment pack.
  • SOC 2 Trust Services Criteria and ISO 27001 Annex A controls matrix mapping each control to concrete evidence in the product, stating plainly where a policy or certification is still required.
  • Latest baseline scan: 0 High, 9 Medium, 7 Low findings; mediums (webapp CSP/SRI, the /docs Redoc page, the OpenAPI servers base path) are tracked to fix.
  • PDF-source controlled documents render byte-faithful to the signed original, watermarked, with the signature manifest appended as an extra page.
  • The automated security baseline now also produces an SBOM, a dependency-vulnerability scan, static analysis and a secrets scan (syft, grype, semgrep, gitleaks), folded into the trust evidence.
  • Tenant audit trails, including every security event, can stream to a syslog collector (RFC 5424 over TCP/TLS) or to Splunk, Datadog or a generic HTTPS collector, batched and retried with a delivery log.
  • mTLS, OPC-UA, SAML and signing certificates are tracked with 30-day and 7-day expiry alerts.
  • Every platform release gets a computed impact report (routes added or changed, affected OQ cases, suggested validation impact) and a downloadable validated-upgrade pack PDF.
What we do not claim

Gaps we know about

Certs

No SOC 2, no ISO 27001 yet.

Controls are listed here and can be inspected in a pilot, now backed by a SOC 2 / ISO 27001 Annex A controls matrix mapping each control to evidence, and by automated ZAP and npm audit scan results. Certifications will be announced when they exist.

At rest

No column-level encryption.

Data at rest is protected by host and disk controls, not by application-level encryption. Database connections can require TLS.

Passwords

No password history yet.

Length, expiry, lockout and 2FA are enforced; reuse prevention and complexity classes are on the list.

CSP

CSP is tuned, not yet report-only.

A content-security policy ships on the web app, tuned for certificate and report iframes, PDF downloads and the customer portal. Directives were tightened — frame-ancestors, worker-src, and no wildcard image sources — and it is not yet in report-only/strict-nonce mode. Inline scripts remain and are documented.

Hosting

Cloud today; on-premise on request.

The platform runs as containers behind a Cloudflare tunnel. On-premise deployment for contracted customers uses the same containers.

Reporting a vulnerability

If you find something

Tell us from inside the product (the built-in helper escalates to a human with the context attached) or through the pilot request form on the demo. We fix in hours and days and will credit you if you want it.

Do not test against other tenants' data. Use your own workspace, or ask for a throwaway one: onboarding creates a tenant in seconds.

Beta · free while we build it with the first labs and plants

Bring one lab and your real history.

The tour runs the working platform, not a mockup. Pilot on your own instruments with your own imported history — we set it up with you, and fixes ship in hours and days, not release cycles.