EV-signed artefacts. RS256 licence validation. Fail-closed by design.

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 EV code-signed manifests validated via RS256 JWT licence tokens. 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

Tier boundaries are hard security boundaries enforced by EV-signed manifests. 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, logged in the HMAC-SHA256 tamper-evident audit chain.

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.

HMAC-chained immutability

• Every audit record includes an HMAC-SHA256 hash of the previous record, forming a chain designed to reveal undetected alteration.
• 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.
• PostgreSQL append-only audit store backs production persistence. All entries are retained for a minimum of 7 years. WORM-immutable blob storage is planned but not yet shipping.

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.

Formal evidentiary review support

• The audit substrate supports structured export workflows where they are licensed and in contractual scope.
• Structured JSON export is available for supported workflows such as DSAR responses, investigations, and other agreed review processes.
• Minimum 7-year retention is enforced by policy and cannot be overridden by tenant configuration below that floor.
• Stronger non-repudiation depends on the signed export path and verification workflow, not append-only storage alone.
• 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).

Testing schedule

• An external penetration test is scheduled in the 2026 assurance cycle. The first test has not yet completed.
• Planned scope: 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) — this IS running today.
• Planned SLA: critical findings will be remediated within 7 days, high within 30 days, with results tracked to closure.

Report availability

• Executive summaries from completed penetration tests will be available to prospective and current customers under NDA once the first assessment has completed.
• To request the first summary when available, 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 will include: scope, methodology, critical/high finding counts, and remediation status.
• NDA must be executed before any summary is shared. Template NDA available on request.

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.