June 6, 2026

ed25519-signed threat feeds that work offline

Threat intelligence that only works online is threat intelligence that fails during the outage you are trying to survive. DORA resilience testing and NIS2 continuity expectations both assume critical detective controls keep operating when central services degrade. DNS agents that fetch unsigned blocklists over HTTPS on every query fail that test the moment CDN or vendor API latency spikes.

Bundle, sign, verify locally

ClearScreen ships URLhaus, OpenPhish, and PhishTank domains in a single bundle refreshed every fifteen minutes at the edge, signed with ed25519. Agents verify the signature before applying indicators and retain the last good bundle on disk. Policy enforcement continues with stale-but-trusted data rather than opening resolution because a fetch timed out.

Document the maximum staleness your risk appetite accepts — many CISOs accept 24 hours for phishing domains on road-warrior laptops, fewer for malware C2 in trading-floor VLANs. Your ICT risk register should state that figure explicitly.

Why ed25519

Signature verification on every endpoint must be cheap in CPU and code size. ed25519 gives fast verification without pulling in heavyweight TLS parser dependencies for the bundle itself. Public keys ship with the agent; private keys stay in the signing pipeline with rotation documented for vendor-risk questionnaires.

Operational checks

Monitor bundle version skew across the fleet. Devices more than two refresh cycles behind may be offline, misconfigured, or under attack to suppress updates. Alert before users notice phishing slips through. Include a tabletop scenario where the signing service is unavailable for four hours — endpoints should still block with the previous bundle and log the version in each block event for post-incident review.

Contrast with cloud-only DNS security: if the resolver is the control, laptop DNS settings drift or VPN drop equals unprotected browsing. Local signed bundles invert that dependency.

Evidence for vendor and regulator reviews

Keep a one-page feed architecture diagram for questionnaires: sources (URLhaus, OpenPhish, PhishTank), signing algorithm, refresh cadence, agent verification steps, and maximum staleness under outage. When a regulator asks how you detect phishing on a laptop that has not synced in twelve hours, point to the retained bundle version in block logs — not to a SLA PDF from a resolver vendor. Rotate signing keys on a published schedule and store verification public keys in the agent release manifest so supply-chain reviews can trace trust roots the same way they trace TLS certificate chains.

Estimate feed coverage and refresh risk with the threat feed coverage estimator when scoping your deployment.