Skip to main content
Security Overview

Cryptographically governed. Fail-closed by design.

IdentityFirst is built on a single, auditable codebase with four capability tiers activated only through EV-signed manifests. Every action is logged. Every boundary is enforced. Every failure closes down rather than opens up.

Contact Security Team Penetration Testing

Architecture

Platform architecture overview

One codebase. Four licensed tiers. Capability boundaries enforced by cryptography, not configuration.

Single-codebase architecture

  • All four product tiers (MRI, Core, Enhanced, AISF) are implemented in one unified codebase — no forks, no separate code paths, no configuration-only tier switches.
  • Capabilities are activated by cryptographically signed manifests. A lower tier can never silently gain access to a higher-tier capability.
  • Shared primitives — identity graph, evidence engine, policy fabric, orchestration layer, audit substrate — are reusable across all tiers.
  • The platform is modular. Each capability declares its tier availability, signature reference, dependencies, and evidence outputs in its manifest.

Four-tier capability model

  • MRI: Baseline intelligence, reporting, evidence collection. Read-only by default.
  • Core: Foundational identity fabric, continuous monitoring, standard orchestration.
  • Enhanced: Advanced analytics, extended policy packs, enriched evidence models.
  • AISF (Augmented Identity Security Fabric): Full multi-agent orchestration, governance-aware pipelines, quantum-safe controls.
  • Tier boundaries are hard security boundaries. Violation causes a fail-closed drop to MRI-only mode, not a silent degradation.

Multi-tenant isolation

  • Per-tenant API keys with constant-time comparison. No shared credentials between tenants.
  • TenantEnforcementMiddleware validates tenant identity on every inbound request; cross-tenant data access is architecturally rejected.
  • All data is tagged with a verified tenant identifier before persistence. Mixed writes are rejected at the service layer.
  • Tenant suspension is available as an immediate operator action, cryptographically logged.

Root of Trust

EV code signing certificate as root of trust

The IdentityFirst EV Code Signing certificate is the cryptographic root of trust for the entire platform. No unsigned artefact can activate any capability.

What is signed

  • All licence manifests, capability manifests, policy bundles, and module activation descriptors must be digitally signed using the EV certificate.
  • Windows PE binaries are signed with signtool using RFC 3161 timestamps.
  • NuGet packages are signed with dotnet nuget sign.
  • SHA256 checksums are generated for every release artefact and included in the release manifest.

Three-gate module loading

  • A module may only load if: (1) its capability ID appears in a valid EV-signed manifest; (2) the active licence tier authorises it; and (3) its integrity hash matches the signed descriptor.
  • All three gates must pass. Failure in any gate causes a fail-closed drop to MRI-only mode.
  • Every activation event is logged with: capability ID, tier, signature result, module hash, and policy decision.
  • There are no debug switches to disable signature verification. The platform assumes adversarial conditions.

Key custody

  • The EV private key is held in a DigiCert HSM. It never appears in source control, CI/CD pipelines, or any runtime environment.
  • Code signing is performed by a dedicated Azure DevOps signing pipeline (identity-mri-signing.yml) with strict access control.
  • Per-startup random signing keys are used in development. Production keys must be provisioned from HashiCorp Vault — hardcoded keys are blocked at CI.
  • Vault-backed secret management means no credentials are ever stored in configuration files or environment variables in production.

Manifests

Cryptographic manifest verification

Capability manifest structure

  • Every module declares: capabilityId, tierAvailability, signatureRef, dependencies, policyHooks, and evidenceOutputs.
  • Manifests are validated at runtime before any module is allowed to initialise.
  • If a manifest is missing, invalid, expired, or its hash does not match the signed descriptor, the system drops to MRI-only mode and logs a security event.
  • No configuration-only mechanism can elevate a licence tier. Tier elevation requires a new signed manifest.

Forbidden bypass patterns

  • There are no environment-variable bypass flags. DEBUG_SKIP_LICENCE or equivalent is not a feature of IdentityFirst.
  • Unsigned capability activation (signed=False equivalent) is not possible. The activation path always requires a valid signature.
  • Config-based tier elevation (config["tier"] = "aisf" equivalent) is not possible. Tier is determined solely by the signed manifest.
  • These constraints are enforced by automated guardrail tests that run on every pull request and block merge on failure.

Audit Substrate

Immutable audit substrate — 7-year retention

Every action, every approval, every capability activation generates a tamper-evident, cryptographically linked audit record.

HMAC-chained immutability

  • Every audit record includes an HMAC-SHA256 hash of the previous record, forming a chain that makes undetected alteration impossible.
  • Audit records cannot be updated or deleted via any API surface. The store is append-only.
  • Null or blank actor values cause the write to be rejected at the service layer — no anonymous actions are permitted.
  • MySQL ImmutableAuditStore backs production persistence. All entries are retained for a minimum of 7 years.

What is logged

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

Tribunal-defensible evidence

  • Audit logs are structured for tribunal-defensible evidence under UK and EU regulatory frameworks.
  • Structured JSON export is available on demand for regulatory proceedings, DSAR responses, and internal investigations.
  • Minimum 7-year retention is enforced by policy and cannot be overridden by tenant configuration below that floor.
  • Audit logs cannot be erased in response to a GDPR erasure request during the legal retention period — the legal basis is Art. 6(1)(c) (legal obligation).

Data Residency

Data residency options

Deployment mode Data location Customer control Notes
SaaS (EU region) AWS eu-west-1 (Ireland) or eu-west-2 (London) Region selected at contract Data never leaves the selected AWS region. Sub-processors are co-located.
SaaS (UK region) AWS eu-west-2 (London) Region selected at contract UK-only residency for UK-regulated customers.
Connected On-Premises Customer-managed data centre Full customer control Platform deployed within customer infrastructure. IdentityFirst does not host data.
Air-Gapped Customer-managed, network-isolated environment Full customer control No outbound connectivity. Licence validation uses offline manifests signed by the EV certificate. Suitable for classified and high-security environments.

Penetration Testing

Penetration testing

Independent penetration tests are conducted annually by a CREST-accredited provider.

Testing schedule

  • Annual full-scope external penetration test by a CREST-accredited provider.
  • Scope covers: SaaS API surface, authentication and authorisation controls, tenant isolation, connector endpoints, and admin interfaces.
  • Internal security reviews are performed continuously via automated SAST (Semgrep, Bandit), dependency scanning (Trivy, Dependabot), and secret scanning (Gitleaks).
  • Critical findings from penetration tests are remediated within 7 days. High within 30 days. Results are tracked to closure.

Report availability

  • Executive summaries from completed penetration tests are available to prospective and current customers under NDA as part of vendor due diligence.
  • To request a summary, email security@identityfirst.net with subject “Pen test report request”. Include your company name and the context (procurement, annual review, etc.).
  • Full reports (including raw findings) are not distributed. Summaries include: scope, methodology, critical/high finding counts, and remediation status.
  • NDA must be executed before the summary is shared. Template NDA available on request.

Responsible Disclosure

Responsible disclosure policy

We take security reports seriously and commit to a transparent, good-faith response process.

How to report

  • Email security@identityfirst.net with a clear description of the vulnerability.
  • Include: affected component, steps to reproduce, potential impact assessment, and your contact details.
  • You may also open a GitHub Security Advisory for coordinated disclosure.
  • PGP encryption is available on request for sensitive reports. Request the public key at the security email above.

Response commitments

  • We request a 90-day coordinated disclosure window before public disclosure to allow remediation.
  • We do not take legal action against researchers acting in good faith.
  • We will acknowledge your contribution in release notes unless you prefer anonymity.
Severity Initial response Resolution target
Critical 24 hours 7 days
High 72 hours 30 days
Medium / Low 7 days 90 days
Security contact
security@identityfirst.net

Vulnerability reports, security questionnaires, vendor due diligence, pen test report requests.

GitHub Security Advisories
Open a private advisory

Preferred channel for coordinated disclosure on specific code vulnerabilities.

Back to Trust Centre
View all compliance & security docs

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