Skip to main content
Security Architecture

Multi-tenant. Cryptographically governed. Fail-closed.

IdentityFirst is architected for adversarial conditions. Every capability is EV-signed, every action is logged, every tenant is isolated by design — not by configuration.

Architecture

Architecture overview

Multi-tenant, API-first, cryptographically governed.

Tenant isolation

  • Per-tenant API keys with constant-time comparison — no shared credentials.
  • TenantEnforcementMiddleware validates tenant identity on every request; cross-tenant access is architecturally impossible.
  • Tenant kill-switch: any tenant can be suspended immediately via a signed operator action.
  • All data is tagged with a verified tenant identifier before storage; mixed writes are rejected at the service layer.

Licence & capability gating

  • Every platform capability is activated by an EV code-signed manifest — no capability can load without a valid signature.
  • Three-gate module loading: manifest presence + tier authorisation + integrity hash. All three must pass.
  • Verification failure drops the platform to MRI-only read mode. No silent fallback to a higher tier.
  • The EV private key never enters the repository or CI/CD environment.

Human-in-the-loop controls

  • Every automated remediation action requires explicit human operator approval (Core+ tiers).
  • Agent-generated decisions are logged with evidence references before any action is taken.
  • Operators must authenticate via JWT Bearer; unauthenticated approval requests are rejected.
  • Approval decisions are immutably recorded with operator identity and timestamp.

Authentication

Authentication & access control

Identity & authentication

  • JWT Bearer authentication for operator and API access.
  • Per-tenant API key authentication with X-IdentityFirst-ApiKey header; keys are stored hashed.
  • TOTP multi-factor authentication available for all user accounts.
  • Account lockout enforced after repeated failed authentication attempts.

Authorisation

  • Role-based access policies: MRI tier is read-only; write capabilities are gated to Core+ tiers with a signed licence.
  • Admin endpoints require verified operator identity; unauthenticated access returns 401.
  • Privileged operations require an additional authorisation check against a Human Operator policy.
  • Write permission is evaluated per-tier and per-capability at the request layer.

Rate limiting

  • Redis-backed atomic rate limiting using Lua INCR+EXPIRE scripts — no race conditions.
  • Rate limit state is partitioned per API key, preventing cross-tenant interference.
  • Requests exceeding limits return HTTP 429 with a Retry-After header.
  • In production, Redis unavailability returns 429 (fail-closed). In development, fail-open for local iteration.

Encryption

Encryption

In transit

  • TLS 1.3 enforced on all platform endpoints. TLS 1.2 and below are disabled.
  • HTTP Strict Transport Security (HSTS) with max-age=31536000 enforced in production.
  • Webhook payloads are signed with HMAC-SHA256 so receivers can verify authenticity.
  • All outbound connector requests use TLS certificate validation; insecure connections are rejected.

At rest

  • PostgreSQL, Redis and blob storage encrypted at rest with AES-256.
  • Encryption is managed at the infrastructure layer (AWS KMS / Azure Key Vault) and at the application layer.
  • API keys are stored as hashed values; plaintext keys are never persisted.
  • Sensitive configuration values are loaded from HashiCorp Vault at runtime; never stored in code or environment files.

Key management

  • HMAC-SHA256 chaining across the immutable audit log; each entry includes the hash of the prior entry.
  • EV code-signing certificate (RSA 4096) signs all capability manifests and release artefacts.
  • Signing keys are held in a DigiCert HSM; they never appear in source control or CI/CD pipelines.
  • Per-startup random keys are used in development; production keys must be provisioned via Vault.

Audit Trail

Tamper-evident audit trail

Every action generates an immutable, cryptographically linked audit record.

Immutability

  • HMAC-chained audit log: each entry includes a hash of the previous entry, making undetected alteration impossible.
  • Audit records cannot be updated or deleted via any API surface.
  • Null or blank actor fields cause the audit write to be rejected at the service layer — no anonymous actions.
  • MySQL ImmutableAuditStore backs production persistence; entries are append-only.

Retention & export

  • Minimum 7-year audit log retention (legal obligation; configurable upward per contract).
  • Audit logs are exportable on demand for regulatory proceedings and tribunal evidence.
  • Structured JSON export available via the DSAR API endpoint.
  • Suitable for tribunal-defensible evidence under UK and EU regulatory frameworks.

What is logged

  • Operator identity (authenticated subject from JWT claim).
  • Timestamp and correlation ID for every event.
  • Capability ID, tier, signature verification result and module hash on every activation.
  • Human approval decision, evidence reference and policy outcome for every privileged action.

Certifications

Security certifications

Cyber Essentials

  • Certified. Certificate reference: CE-2025-XXXXX [PLACEHOLDER — update before launch].
  • Covers: boundary firewalls, secure configuration, access control, malware protection, patch management.

SOC 2 Type II

  • Audit in progress. Third-party auditor engaged.
  • Controls mapped to Trust Services Criteria: Security, Availability, Confidentiality.
  • Expected completion: 2026. Report available to prospective customers under NDA.

ISO 27001

  • ISMS established. Gap assessment complete.
  • External certification audit scheduled for 2026.
  • Statement of Applicability available to prospective customers under NDA.

Responsible Disclosure

Responsible disclosure policy

We take security reports seriously and commit to a transparent response process.

How to report

  • Email security@identityfirst.net with a clear description of the vulnerability.
  • Include steps to reproduce, affected component and potential impact assessment.
  • PGP encryption available on request for sensitive reports.
  • We request a 90-day coordinated disclosure window before public disclosure.

Response SLAs

  • We do not take legal action against researchers acting in good faith.
Severity Initial response Resolution target
Critical 24 hours 7 days
High 72 hours 30 days
Medium 7 days 90 days
Security contact
security@identityfirst.net

Vulnerability reports, security questionnaires, pen test evidence requests.

Back to Trust Centre
View all compliance & security docs

Certifications, DPA, sub-processor list, GDPR details.