Your questionnaire, already answered.

MFA is mandatory, not optional — TOTP and WebAuthn are both supported. TOTP is replay-protected by a monotonic counter and recovery codes are single-use. Authentication is first-party (TFID); the platform trusts no claim presented by the client.

Authorization re-reads the caller’s role from the database on every request against a strict hierarchy (Viewer < Member < Admin < Owner). Tampering with a session claim cannot escalate privilege; the highest (super-admin) privilege is gated by deployment configuration at module load. Three CI gates ratchet against authorization regressions.

Enterprise SSO is supported via SAML 2.0 and OIDC, and inbound user provisioning/de-provisioning via SCIM 2.0 with an org-scoped bearer token. Provisioning events are anchored in the signed ledger.

Sessions are opaque, server-side tokens; status and role are re-validated from the database on every request, so revoking a session or a member takes effect immediately. Honest boundary: sessions are not additionally bound to client IP/user-agent (a documented defense-in-depth roadmap item).

Long-lived secrets (collector credentials, sensor secrets) are protected with AES-256-GCM authenticated envelope encryption — a random data key per operation, a 96-bit IV, and a 128-bit authentication tag. Encrypted secrets are stored as the base64 envelope only; a CI audit fails the build if any credential column holds plaintext.

The tenant’s organizationId and the credential kind are bound into the encryption context (AAD). The code refuses to encrypt or decrypt without a non-empty tenant identity, so a credential sealed for one tenant cannot be decrypted under another tenant’s context — GCM tag verification fails.

Stated honestly: there is no HSM / FIPS 140-2 Level 3 path today; the cryptography is software-based, with a pluggable KMS provider (software KMS or HashiCorp Vault Transit). Per-tenant separation is by application-layer encryption-context binding on a shared deployment master key, not a distinct hardware key per tenant.

A key-rotation routine exists but is not yet wired to a production scheduler; rotation is a documented roadmap item. We disclose this as a known gap rather than imply automatic rotation.

HTTP Strict Transport Security is enabled with a two-year max-age, includeSubDomains, and preload; session cookies use the __Host- prefix with Secure/HttpOnly/SameSite. Honest boundary: TLS cipher-suite selection and certificate pinning are handled at the reverse proxy, not asserted in the application.

Isolation is enforced structurally in layers: the data-access layer injects the caller’s tenant scope into every read/write and rejects a cross-tenant query before it reaches the database; a build-time CI gate scans every dynamic id-bearing route and fails the build if any is unscoped; Postgres row-level security policies back key tables; and the cryptographic AAD binding backstops secret access. Behavioral tests prove cross-tenant reads return "not found".

Collectors are read-only and agentless, and read security-relevant metadata only — which identities and credentials exist, their configuration, age, and scope — not the secret values themselves. Connectors to secret managers read a secret’s metadata and never call the "retrieve secret value" API. Application source code is not part of the collected surface.

The same codebase ships in three modes: hosted, self-hosted (nothing leaves to TrustFix), and fully on-prem / air-gapped where a process-wide runtime egress backstop blocks any connection that would leave the LAN. The mode is fail-closed — a misconfigured on-prem image defaults to the most restrictive (air-gap) posture.

The categories of third parties we use to deliver the service are published and kept current. We do not sell customer data.

Every scan, finding, proposed fix, and authority/identity/change event is recorded on an append-only, hash-chained, Ed25519-signed audit ledger with cryptographic inclusion proofs — so any reordering, deletion, or edit is detectable. Each entry is independently Merkle-provable.

The evidence engine maps signed, cryptographically-anchored artifacts to control identifiers across seven frameworks (SOC 2, ISO 27001, NIST 800-53, OWASP ASI, ISO 42001, NIST AI RMF, EU AI Act Annex IV), each with an honest per-control status, and exports signed bundles plus a NIST OSCAL export. A control is only marked satisfied when a real artifact backs it — a no-fabrication rule enforced by the engine.

Stated honestly: artifacts are Ed25519-signed and Merkle-anchored on our own clock, but are NOT anchored to an independent external time authority, and the platform surfaces this truthfully. We do not imply independent trusted timestamping until it is built.

High-signal security events are structured, auto-redacting, and ledger-anchored, and identity/detection events are emitted in the OCSF schema. External SIEM/OTEL streaming and real-time alerting/IR automation are on the roadmap; today the response to a high-signal event is manual.

TrustFix does not hold a SOC 2 report today; a SOC 2 program is in progress. A report is issued only by a licensed CPA firm over an observation period. We will link the report here once an independent auditor has signed off — and never claim "SOC 2 certified" before then. Note: "SOC 2 evidence export" is a product feature for your audit, not a statement about ours.

No. We publish honest control mappings to ISO 27001:2022 Annex A (what enforces each control, and the gaps), but a certificate is issued only by an accredited certification body. Mappings are not a certificate, and we present them as mappings.

A DPA covering our processing of personal data on your behalf is available, alongside the Privacy Policy, Terms, Acceptable Use, and Cookie Policy. (Current legal documents are working drafts pending counsel review, marked as such; executed versions are provided before they take effect.)

Dependency scanning (high/critical severity blocks the build), secret-pattern scanning, a plaintext-at-rest audit that fails non-zero on any plaintext credential column, and a distroless/non-root sensor image measured clean of high/critical CVEs are all in CI.

Not yet on record. A continuous automated tenant-isolation and route-authorization suite runs on every build (BOLA/IDOR is structurally closed and CI-gated), and we have a scoped brief ready to hand a human tester. We do not claim a completed pen-test attestation until one exists.

The sensor image is distroless and non-root, with per-integration allow-listing and CVE measurement. Cryptographic image signing, an SBOM, and build-provenance attestation are disclosed roadmap items.

Report a vulnerability to security@trustfix.dev. We acknowledge promptly and follow a coordinated 90-day disclosure timeline with safe harbor for good-faith research. A formal bug-bounty program is not yet published.

Security events are logged and ledger-anchored, and we notify affected customers of material incidents under the terms of the agreement and DPA, posting them to the public status page. Automated detection/alerting and IR automation are on the roadmap; today triage of high-signal events is manual.

Backups are in place; full-scale air-gap packaging load-testing and an end-to-end disaster-recovery restore drill are disclosed roadmap items rather than completed exercises.