Resurgamus Horizon v1.0.0 is scheduled to be placed on the market in September 2026. Its support period runs five years, ending September 2031.

During that period Resurgamus manages vulnerabilities in the product and in the components it integrates, and provides security updates free of charge to every user, under the AGPL, with an advisory for each fixed issue. Five years is the floor set by Article 13(8) of the Cyber Resilience Act (Regulation (EU) 2024/2847); a secrets vault is long-lived infrastructure, so the expected-use-time exception to go shorter does not apply here.

The end date is stated as month and year, is fixed at the time of supply, and does not move backwards. If a later release extends it, the longer period applies to that release; it never shortens for a version already supplied.

The five years to September 2031 are unconditional. They are not contingent on revenue, funding, commercial uptake, or the project's staffing. That is deliberate: the CRA floor is an obligation owed to everyone the product was supplied to, so making it conditional would defeat it.

What is conditional is anything beyond that date. Resurgamus intends to extend the support period past September 2031, and commercial licensing and paid support are what would fund a longer commitment - potentially a rolling window rather than a fixed end date. Any extension will be announced as a new end date here, in month-and-year form, before the current one lapses. An extension can only ever lengthen the period; it never shortens it, and the absence of an extension never shortens it either.

The commitment attaches to the canonical artifact: the signed container images and the rhorizon_crypto wheel built in CI, verifiable per docs/verifying-images.md and docs/verifying-releases.md.

Platform support is graded, and the grade is part of the commitment - it is not a promise of identical parity everywhere. See docs/COMPATIBILITY.md for the authoritative matrix.

Two dependencies will need migration inside the window, and that work is part of the commitment rather than a reason to shorten it:

• Python 3.12 reaches security end-of-life on 31 October 2028. A migration to a supported interpreter happens before that date.
• OpenBSD supports only its two most recent releases and ships every six months, so the OpenBSD lane is revalidated per release rather than pinned.

Regrading a platform requires a release note and does not affect the canonical artifact's end date. Where technically feasible, users are notified when the support period expires.

Do not open a public issue for security vulnerabilities.

• Paying sponsors / commercial members: email horizon@resurgamus.com. First response within 48 hours, or the shorter time in your support agreement if you have one.
• Everyone else (OSS / AGPL): email security@resurgamus.com. First response within 96 hours.

Include:

• Description of the vulnerability
• Steps to reproduce
• Impact assessment
• Suggested fix (if any)

Two distinct clocks. The first is how fast a human replies to you; the second is how fast a fix ships, and it does not depend on who reported.

Remediation is driven by severity, not by reporter. A critical flaw found by an anonymous reporter is fixed on the same clock as one raised by a sponsor:

Security fixes ship separately from feature work (fix: commits are already released independently), free of charge, to every user under the AGPL, with an advisory per fixed issue. Paying sponsorship buys attention latency and support, never privileged access to a fix or an embargo extension.

These targets are effort commitments for a small maintainer team, not a contractual uptime SLA. Where one conflicts with a commercial support agreement, the agreement governs for that customer - and can only be shorter, never longer.

• Coordinated disclosure (90-day window)
• Credit will be given in the CHANGELOG unless you prefer anonymity
• No bug bounty program at this time

In scope:

• Authentication or authorization bypass
• Secret leakage (plaintext in logs, responses, or DB)
• Cryptographic weaknesses
• Audit chain bypass or forgery
• Container escape or privilege escalation

Out of scope:

• Attacks requiring physical access to the host
• Social engineering
• DoS (rate limiting is implemented but not hardened for DDoS)
• Issues in third-party dependencies (report upstream, but let us know)

Resurgamus Horizon does not aim to be "compliant" by checkbox; the security design is mapped to recognized frameworks so an auditor can trace each control to a primitive, an endpoint, or a piece of code.

Resurgamus Horizon maintains a control-by-control readiness assessment for the EU Cyber Resilience Act (Regulation (EU) 2024/2847):

Roadmap goal: complete operational CRA readiness by 11 September 2026, including the vulnerability-reporting workflow, manufacturer documentation, support-period policy, and remaining Annex I measures.

Detailed evidence, gaps, legal-role analysis, and the remediation roadmap: docs/CRA-COMPLIANCE.md. Official EU references: CRA summary and reporting obligations.

docs/SECURITY-AUDIT.md is the living remediation tracker - current findings, status, and the work in progress to address them. Expect it to change between releases; consult it for the up-to-date posture, not for a frozen audit report.

Crypto stack (docs/THREAT-MODEL.md for the MITRE/ASVS mappings):

flowchart TD
    PW["Master password"] -- "Argon2id (256 MB, t=3, p=1)" --> MK["master_key"]
    MK -- "HKDF-SHA512" --> HMAC_K["hmac_key"]
    MK -- "HKDF-SHA512" --> DEK_K["dek_key"]
    MK -- "HKDF-SHA512" --> AUDIT_K["audit_key"]

    HMAC_K --> TOK["Token lookup (HMAC-SHA512, O(1) B-tree index)"]
    AUDIT_K --> CHAIN["Audit chain signatures (HMAC-SHA512, tamper-evident)"]

    DEK["Per-secret DEK (fresh, random)"] -- "XChaCha20-Poly1305" --> CIPH["Encrypted secret in DB"]
    SECRET["Secret plaintext"] -.->|"encrypted under"| DEK
    DEK_K -- "AES-256-GCM wrap" --> WRAPPED["Wrapped DEK in DB"]
    DEK -.->|"wrapped as"| WRAPPED

    style MK fill:#4a2b7a,color:#fff
    style DEK_K fill:#2b4a7a,color:#fff
    style HMAC_K fill:#2b4a7a,color:#fff
    style AUDIT_K fill:#2b4a7a,color:#fff

• Argon2id (256 MB, t=3, p=1) for password -> master key
• HKDF-SHA512 to derive hmac, dek, audit sub-keys
• XChaCha20-Poly1305 for secrets, each with its own DEK
• AES-256-GCM to wrap the DEKs (wrap key lives in Rust, mlock'd)
• HMAC-SHA512 for token lookup (O(1) B-tree index) and chained audit signatures

Additional controls:

• Shamir Secret Sharing (M-of-N) for the master password / unseal key
• 2FA on unseal: WebAuthn/FIDO2, YubiKey HMAC-SHA1, or TOTP (RFC 6238)
• Mutation audit chain dual-written to PostgreSQL + daily JSONL; read records protected by signed Merkle checkpoints and sealed archives
• Container is read-only, non-root (uid 1500), all caps dropped, no-new-privileges, pids/memory limits
• Keys are zeroed on seal - Rust zeroize performs the wipe on Drop
• Multi-worker key custody: only the master process holds the sub-keys; followers delegate every crypto op over a 0700 filesystem-path Unix socket (peer-UID checked via SO_PEERCRED, fail-closed) and hold one Shamir share each. The legacy /dev/shm key-share path was removed

Resurgamus Horizon uses well-known primitives and audited libraries.

The storage core uses 256-bit symmetric primitives, information-theoretic Shamir sharing, passphrase-encrypted backups, and HMAC audit signatures. Shor's algorithm does not break those primitives; Grover's algorithm reduces the brute-force margin of symmetric keys. Transport prefers hybrid ML-KEM (X25519MLKEM768) on the UI/inter-node TLS and PostgreSQL paths, but operators must verify that each live connection negotiated the hybrid group. WebAuthn and certificate signatures remain classical. See docs/POST-QUANTUM.md.

• docs/THREAT-MODEL.md - full MITRE ATT&CK + OWASP ASVS Level 2 mapping, explicit limitations
• docs/SIDE-CHANNELS.md - constant-time design, exhaustive amd64/aarch64 functional tests, native assembly gates on both architectures, memory protection, and residual risks
• docs/POST-QUANTUM.md - post-quantum posture: hybrid ML-KEM transport + PQ-by-construction storage core
• docs/NIS2-COMPLIANCE.md - NIS2 Art. 21 control matrix
• docs/SECURITY-AUDIT.md - internal security audit findings + remediation log
• docs/FAIL2BAN.md - IP-level brute-force protection
• docs/TLS.md - native HTTPS configuration