Crossfyre is in open beta with a solid core: distributed nodes, crash-safe execution, three recon engines, workflows, live findings, Valkyrie triage, teams, notifications, scheduling, and a CLI that ties it together. This post is about what comes after that, and we want to be honest about one thing up front: these are directions, not promises with dates attached. We do not announce ship dates for work we have not finished. What follows is where we are pointed and why.
Everything below is on the roadmap, in varying stages of development. None of it is live yet. When something ships, we will say so plainly. If you want to influence the order, the last section is for you.
Theme one: from surface to checked findings
A dedicated vulnerability-scanning engine
Today the engines map attack surface: subdomains, ports, content, services. Knowing the surface is recon. The next step is checking it. We are building a dedicated vulnerability-scanning engine that sits on top of the recon layer and turns discovered surface into checked, evidence-backed findings.
Why it matters: right now, the jump from "here is an interesting host" to "here is a confirmed issue with evidence" is manual. A vuln engine that runs across your fleet, with the same crash-safe and reserve-then-reconcile guarantees as the recon engines, closes that gap inside the platform instead of sending you out to a separate tool with its own state and its own billing. It also gives Valkyrie something stronger to reason about: actual checks and evidence, not just fingerprints.
Theme two: composing engagements, not running scans
Mission Planner
A workflow is one scan. A real engagement is many, chained: enumerate subdomains, feed the live ones into content discovery, branch on what you find, port-scan the interesting hosts, and only then run the heavier checks. Today you orchestrate that sequence yourself. Mission Planner is the visual composer for it.
- Chain workflows so the output of one feeds the input of the next, instead of copy-pasting targets between runs.
- Conditional branching: gate a stage on what the previous stage found, so you do not run an expensive check against surface that does not warrant it.
- Scheduled campaigns: run the whole multi-stage mission on a recurring basis across your fleet, with results pushed to you.
Why it matters: the value of a distributed fleet is wasted if a human has to manually shepherd each scan into the next. Mission Planner turns a sequence of one-off scans into a repeatable, end-to-end recon mission you define once and rerun.
Theme three: deeper, more accurate triage
Expanded Valkyrie
Valkyrie today reads scanner output and ranks findings with severity and context (see the Valkyrie deep-dive). That is triage. The roadmap takes it from reading output to probing the surface.
- Deeper context: pulling more signal together across a finding to sharpen the severity and the reasoning behind it.
- Payload mutation: working alongside the vulnerability-scanning engine to craft and adjust probes, digging into candidate vulnerabilities rather than just flagging them.
- Fewer false positives: using that active probing to confirm or rule out findings, so a high-severity flag means more.
Why it matters: triage tells you where to look. The next version starts doing some of the looking, which both saves time on confirmation and cuts the noise that erodes trust in any ranking. We are building this carefully and will keep being precise about what it does versus what it suggests.
Theme four: opening the platform
An extension marketplace
The engines (mach, voyage, pulse) are open source and plug into nodes and workflows the same way. The marketplace opens that interface up: an ecosystem of engines and integrations, built by the team and by the community, that you can discover, install across your fleet, and publish to.
Why it matters: no single team can build every scanner the field needs. A custom engine for a niche protocol, an integration with your reporting pipeline, a specialized discovery tool: the marketplace lets those live inside Crossfyre and run with the same orchestration, crash-safety, and findings pipeline as the core engines, instead of as one-off scripts you maintain alone.
Theme five: running it yourself
Enterprise self-hosted control plane
Some teams cannot send scan data or orchestration through a hosted control plane, full stop. For them we are working toward a self-hosted control plane: the same orchestration, scheduling, and findings layer that runs the hosted platform, deployable inside your own environment.
Why it matters: the node agent and engines are already open source and run on your hardware. The piece that is hosted is the control plane. For teams with strict data-residency or air-gap requirements, being able to run that piece themselves is the difference between adopting Crossfyre and not being able to. This is the largest of the directions here and the one we will talk about most carefully as it firms up.
These are directions, not dates
We will keep saying this because it matters: nothing above has a ship date, and we will not pretend otherwise to make a roadmap look more impressive. Some of this is close, some is further out, and priorities will shift as we learn from beta. What will not shift is that we tell you clearly when something is live versus when it is still on this list.
The fastest way onto this list, or up it, is to tell us what is in your way. Beta feedback is how we decide what to build next.
The Crossfyre Team
If any of these matter to your work, or if the thing you need is not here at all, we want to hear it. Join the Discord, run the beta, and tell us what is missing. The people who show up early shape the order of this list.
Run the beta, then tell us what to build next.
Start free