Security
opensecstack v1.0.0 ships with strong cryptographic primitives, structured audit, and role-enforced APIs. Whether those controls are sufficient depends on what you are defending against. This page defines the three deployment tiers and the cross-platform security guarantees that every opensecstack deployment provides. For the release cadence and version compatibility, see Versioning & Releases.
For the detailed per-tier control matrix and known gaps, see docs/security-maturity.md and the five-layer defence model in docs/security-architecture.md.
Deployment tiers
v1.0.0 is not a compliance certification — it is a quality mark meaning the code compiles, test suites pass, the API surface is frozen under semver, and the cryptographic primitives are state-of-the-art. Fitness for a specific deployment profile is tier-dependent.
| Tier | Your situation | Is v1.0.0 sufficient? |
|---|---|---|
| Standard | Single region, trusted operator — SaaS, NGOs, public administration, research labs | Yes — production-ready out of the box |
| Elevated | Multi-region, multi-tenant, zero-trust network expectations | Yes, with ops-layer additions — Vault, service mesh (mTLS), OpenTelemetry |
| High assurance | Banking Tier 1, national CSIRTs, NIS2 essential entities, defence contractors | Not yet — wait for v1.1 or add compensating controls |
Tier 1 — Standard deployment
For SaaS companies, mid-sized enterprises, NGOs, regional public administration, and internal corporate deployments.
Key controls shipped out of the box at this tier:
| Control | Implementation |
|---|---|
| API authentication | HS256 JWT with exp/nbf checks; alg: none rejected |
| Authorization | RBAC — 5 canonical roles, per-route guards (RequireWrite, RequireDelete) |
| Webhook authentication | HMAC-SHA256 with ±5-minute replay window, per-source secrets, 503 on empty secret |
| Inter-service signing (platform → CITADEL) | HMAC-SHA256 via X-Citadel-Signature |
| Audit integrity | CITADEL WORM chain — TripleHash (SHA-256 + SHA-512 + BLAKE3), Ed25519 anchors every 100 entries |
| Dual-control enforcement | CITADEL NDS — every privileged action requires operator ≠ verifier |
| Password and API-key hashing | Argon2id (RFC 9106) + HMAC-SHA256 pepper via sdk/go/password or opensecstack-password |
*_AUTH_SECRET, *_AUTH_PEPPER, CITADEL_KEY_SECRET, and every *_WEBHOOK_*_SECRET) are set to at least 32 random bytes and are not committed to git or embedded in container images.Tier 2 — Elevated deployment
For multi-region SaaS, large enterprises, organisations with zero-trust mandates, and multi-tenant deployments.
v1.0.0 is achievable at this tier with standard enterprise operations tooling — no code changes are required from you. The ops-layer additions you provide:
- Secrets management — HashiCorp Vault, AWS KMS, GCP KMS, or Azure Key Vault as the source of truth; short-lived sidecars inject secrets at start-up
- Network-level trust — service mesh (Istio, Linkerd) enforcing mTLS between every platform pair, or Cloudflare Tunnel / Tailscale for east-west traffic
- Distributed tracing — OpenTelemetry collector forwarding
traceparent/tracestateheaders across platforms - Rate limiting — Envoy filter or API gateway with Redis-backed distributed buckets
Known gaps planned for v1.1: JWKS endpoints on each platform, W3C Trace Context cross-platform propagation, webhook event deduplication, and mTLS-ready deployment templates.
Tier 3 — High assurance
For banking Tier 1, national CSIRTs, critical public utilities (energy, water, telecom), NIS2 essential and important entities subject to competent-authority audit, and defence contractors.
If you must deploy now at this tier, compensate with operational controls: HSM-backed Vault, strictly segmented networks, and mandatory 2-person release reviews. Track the v1.1 milestone for every Tier 3 gap.
Cross-platform security guarantees
Every opensecstack deployment — regardless of which platforms are installed — provides the following guarantees:
| Guarantee | Enforced by |
|---|---|
| Every privileged action is cryptographically evaluated | CITADEL MARSHAL 5-gate engine |
| Every decision is WORM-logged with TripleHash integrity | CITADEL WORM chain (SHA-256 + SHA-512 + BLAKE3) |
| Tamper-resistance via Ed25519 anchors | CITADEL chain anchors (every 100 entries) |
| Separation of Duties enforced at protocol level | CITADEL Gate 3 (NDS) — operator ≠ verifier, different role groups |
| All inter-platform webhooks HMAC-signed, replay-protected | IRFlow webhook spec (±5-minute window, per-source secrets) |
| Single sign-on with central MFA across all platforms | sinauth OIDC (RS256 + JWKS, PKCE S256, TOTP) |
| All API clients JWT-authenticated with RBAC | Platform auth middleware — 5 canonical roles |
| Password hashing with Argon2id + server-side pepper | sdk/go/password + sdk/python-password |
Responsible disclosure
Security vulnerabilities in any opensecstack platform should be reported privately before public disclosure. See SECURITY.md for the scope, disclosure process, and SLA. Each platform also ships its own SECURITY.md covering platform-specific scope and the threat model for that service.
Post-quantum strategy
NIST PQC standards were finalised in 2024. NIS3 (projected 2030–2032) will likely mandate migration. opensecstack is moving before it is mandatory, starting from algorithm agility rather than a single disruptive cutover.
v1.0.0 uses Ed25519 chain anchors and TripleHash as the baseline. The roadmap:
| Version | Year | Action |
|---|---|---|
| v1.0.0 | 2026 | Ed25519 anchors + TripleHash. Baseline. |
| v1.1 | 2026–2027 | Algorithm-identifier schema fields added. No breaking change. |
| v2.0 | 2028 | Hybrid Ed25519 + ML-DSA signatures. |
| v2.5 | 2029 | QuintHash (TripleHash + 2 PQ-resistant primitives). |
| v3.0 | 2030 | ML-DSA default. Aligned with expected NIS3 transposition. |
| v4.0 | 2033 | Ed25519 signing retired; historical verification retained. |
The design principle is algorithm agility — schema fields carry algorithm identifiers from v1.1 so that the v2.0 hybrid switch is a configuration change, not a breaking API migration. Historical WORM chain entries remain verifiable after the algorithm transition.
See docs/post-quantum-roadmap.md and ADR-011 for the full rationale.