Trust & Security
IdentityFirst is built with security at its core — from EV code signing to tamper-evident audit trails. Here is the current status and available documentation.
This trust centre mixes runtime-backed status, curated diligence material, and static policy statements. Live platform status is called out separately when the platform API is reachable.
Certifications
Compliance & certifications
We only claim a certification when it has been independently verified. Status is updated on every change.
ISMS established. Gap assessment complete. External audit scheduled for 2026.
Audit work is in progress. This is not represented as a completed certification until independently issued.
Current NCSC Cyber Essentials certification. Cyber Essentials Plus remains underway and is not claimed as complete here.
ICO registered ZC031428. DPA available. Full data subject rights implemented.
Security Architecture
Built on verifiable security primitives
Every security control in IdentityFirst is architectural, not configurational. There are no bypass flags, no debug switches, and no unsigned activation paths.
EV Code Signing
Build artefacts (Windows PE binaries, NuGet packages, Docker images) are EV code-signed via DigiCert HSM (RSA 4096). The private key never leaves the HSM. Capability activation paths are signature-checked against the governed trust chain before licensed features are enabled. A module that cannot be validated against the EV-signed descriptor cannot load — the platform fails closed, not open.
Architecture detailTamper-Evident Audit Trail
Every action is logged to an HMAC-SHA256 chained audit store (per-deployment key) with 7-year retention. Records are append-only — no API surface permits deletion. Null actor values are rejected at the service layer, so every entry has a verified identity attached. Formal evidentiary verification depends on the export and verification path used.
Architecture detailZero Trust Principles
No standing privileges. Human-approved write paths are gated above MRI, with JIT elevation and multi-party approval available only on higher-tier governed workflows. Approval evidence is stored in the tamper-evident audit substrate, and per-tenant API keys enforce tenant-scoped access boundaries.
Architecture detailSecurity Practices
Encryption, key management & data handling
All data is encrypted at rest and in transit. Keys are managed in hardware security modules and never appear in application code or CI/CD pipelines.
Encryption in Transit
TLS 1.2+ enforced on all platform endpoints with HSTS (max-age=31536000).
TLS 1.0 and 1.1 are disabled. All inter-service communication uses mTLS where supported.
Webhook payloads are signed with HMAC-SHA256 for receiver verification.
Encryption at Rest
AES-256 encryption for all data stores: PostgreSQL, Redis and blob storage. API keys are stored as one-way hashes; plaintext keys are never persisted. Sensitive configuration is loaded from HashiCorp Vault at runtime — never stored in code, environment files or container images.
Key Management
Secrets and signing keys are managed via HashiCorp Vault with short-lived leases. The EV code-signing private key (RSA 4096) is held in a DigiCert HSM and never exported. Per-startup ephemeral keys in development ensure dev-mode tokens are non-transferable.
Data Handling
Tenant isolation & data handling
Every customer's data is isolated at the database, API and application layers. Cross-tenant access is architecturally impossible.
Tenant Isolation
- Per-tenant API keys with constant-time comparison — no shared credentials.
TenantEnforcementMiddlewarevalidates tenant identity on every request.- PostgreSQL Row-Level Security (RLS) policies enforce tenant boundaries at the database layer.
- All data is tagged with a verified tenant identifier before storage; mixed writes are rejected at the service layer.
Data Residency
- Connected SaaS is hosted in the UK by default on IONOS Cloud (London). Alternative regional hosting or customer-hosted deployments are agreed explicitly in writing before deployment.
- Residency commitments are fixed by written contract for each customer deployment.
- Sub-processor and transfer details are maintained in the Sub-Processors list.
- Air-gapped and sovereign deployment paths available — contact security@identityfirst.net.
Authentication
Authentication & access control
No standing privileges. Every request is authenticated and authorised against a signed licence and role-based access policy.
Supabase Auth & JWT
User authentication is handled via Supabase Auth with JWT bearer tokens. Licence tokens are RS256-signed JWTs in production and staging; HMAC-SHA256 is permitted in development only and explicitly rejected in production. Token validation is fail-closed — any JWT failure denies the request.
Role-Based Access Control
RBAC policies enforce least-privilege access. MRI tier is read-only; write capabilities require Core+ licence and explicit operator approval. Admin endpoints require verified operator identity. Privileged operations are gated by Human Operator policy.
Rate Limiting
Redis-backed atomic rate limiting using Lua scripts — no race conditions. Limits are partitioned per API key to prevent cross-tenant interference. In production, Redis unavailability returns HTTP 429 (fail-closed).
Testing & Response
Penetration testing & incident response
Penetration Testing
- Planned: annual independent third-party penetration testing is part of the 2026 assurance programme. The first assessment has not yet completed.
- Where independent testing is commissioned, scope covers the platform API, authentication flows, tenant isolation boundaries, and infrastructure relevant to the agreed deployment.
- Critical and high findings from commissioned testing will be tracked to resolution through the internal remediation process.
- Testing summaries will be shared only where a completed test exists and disclosure is appropriate. Contact security@identityfirst.net.
Incident Response
- 24-hour notification SLA for confirmed security incidents affecting customer data.
- Documented incident response playbook covering detection, containment, eradication and recovery.
- Post-incident reports provided to affected customers with root cause analysis and remediation steps.
- All incidents are logged to the HMAC-SHA256 tamper-evident audit chain for regulatory and forensic purposes.
Supply Chain
Software supply chain security
Every release artefact is traceable from source commit to signed binary.
EV Code Signing
All release binaries (Windows PE, NuGet, Docker images) are signed with an Extended Validation certificate held in a DigiCert HSM (RSA 4096). The private key never leaves the HSM.
Container Image Signing
Docker images are signed using Notation/COSE (cosign-compatible). Image digests are pinned in Helm charts and verified at deployment time. No unsigned image can be deployed to production infrastructure.
SBOM & Dependency Scanning
Software Bill of Materials (SBOM) generated for every release in CycloneDX format. All dependencies are pinned, scanned with Trivy and Dependabot, and reviewed for known vulnerabilities before merge.
Sub-Processors
Key infrastructure sub-processors
A summary of key sub-processors. The full list with data categories and change notification commitments is available at Sub-Processors.
| Sub-Processor | Purpose | Location |
|---|---|---|
| IONOS SE (IONOS Cloud) | Cloud infrastructure (compute, storage, networking) — current production hosting for UK SaaS deployments. | United Kingdom (London) |
| Supabase | Authentication and user management | EU (AWS eu-west-1) |
| DigiCert | HSM-backed EV code signing and certificate management | United States |
| HashiCorp Vault | Secrets management and key rotation | Co-located with platform |
| Stripe | Payment processing | United States / EU |
30-day advance notification is provided before any sub-processor change. Full list: Sub-Processors.
Data Residency
Your data stays in your region
UK-hosted SaaS uses IONOS Cloud (London) by default. EU-region hosting and customer-hosted deployments are available by written contract. On-premises and air-gapped deployment options give you full infrastructure sovereignty.
Connected deployment surfaces
- UK customers: IONOS Cloud (London) by default.
- EU or customer-hosted deployments: Hosting provider and region are selected at contract. Data remains in the contracted region.
- Data residency region is selected at contract and locked in the DPA. It cannot be changed without a contract amendment and written customer consent.
- Sub-processor and transfer terms are documented in the DPA and sub-processor schedule rather than implied generically on this page.
Planned offline / sovereign paths
- Air-gapped and other sovereign deployment paths are legitimate planning targets.
- They are planned, not currently shipped from this repo as an authoritative packaged surface.
- Offline licence validation and supportability expectations must be agreed through written scope before they are represented as deliverable.
- Contact security@identityfirst.net to discuss whether a planned offline path is appropriate for your environment.
For full data residency, transfer mechanism, and sub-processor details see Data Protection and Sub-Processors.
Platform Status
Platform security posture
Current platform summary from the platform API endpoint
/v1/platform/trust-summary.
Operational Static trust-centre fallback snapshot • EV code-signing manifest valid • HMAC-SHA256 tamper-evident audit chain active • Data residency controls enforced •
Documentation
Compliance documentation
Everything procurement teams, DPOs and security leads need to evaluate IdentityFirst.
Platform architecture, EV-signed capability manifests, cryptographic manifest verification, tamper-evident audit substrate, data residency options, responsible disclosure.
View detailsSOC 2 Type II in progress, ISO 27001 roadmap, Cyber Essentials certified, Cyber Essentials Plus underway, GDPR materials, and DPA access.
View detailsICO registered (ZC031428), 30-day DSAR SLA, 7-year audit retention, right to erasure, sub-processor list, full data subject rights supported.
View detailsService commitments, incident history, and maintenance policy by supported deployment path and written contract. No blanket public SLA percentage is implied here.
View detailsFull list of third-party processors with data categories, locations and 30-day change notification commitment.
View listGDPR Article 28-compliant DPA. Download the template or request e-signature via DocuSign.
View & downloadResponsible Disclosure
Responsible disclosure
We take security research seriously. If you find a vulnerability in IdentityFirst, we want to know — and we commit to a transparent, good-faith response.
Include: affected component, reproduction steps, and your assessment of potential impact. PGP encryption available on request.
Medium and Low findings receive an initial response within 7 days. We request a 90-day coordinated disclosure window before public disclosure.
We do not take legal action against researchers acting in good faith. We acknowledge your contribution in release notes unless you prefer anonymity.
Includes scope, methodology expectations, and safe harbour statement.
Contact
Security contacts
General security questions, penetration test evidence, vendor security questionnaires.
GDPR enquiries, DSARs and data subject rights. ICO registered ZC031428.
Critical: 24h • High: 72h • Medium: 7 days response SLA.
Company Details
Company registration details
Registered in England & Wales
Morpeth, Northumberland, NE65 8JJ, UK
Content is reviewed quarterly. Sub-processor list updated on every change.