Upload the firewall, cloud and identity configs you already have. Get each finding with the setting it comes from, the paths an attacker could take to your crown jewels, the one change that cuts the most of them, and what's at stake as a dollar range. No agents, no scanning.
Reads exports from 37 vendors; 14 of them — FortiGate, Okta, AWS and the rest — chain into attack paths. Findings are read from your file — line-traced on FortiGate, proven where the config re-parses into a re-checkable proof (FortiGate, PAN-OS, OPNsense), observed for the rest; dollars are modeled and labeled as modeled.
Not a scan, not a guess — the engine reads the export you already have. On a FortiGate export, each finding cites the lines it was read from, like this one. Other vendors' findings are read from your file too.
31config firewall policy32 edit 9933 set srcintf "any"34 set dstintf "any"35 set srcaddr "all"36 set dstaddr "all"37 set service "ALL"38 set action accept39 set status enable40 next
traced to lines 33–38
Read from the file itself, not inferred. The line citation is shown for FortiGate exports; this one is the seeded sample.
Attack paths are one of the questions your twin answers — the same twin also prices your risk, scores your frameworks, and re-proves what it can on every upload. This board is an illustrative sample estate, drawn in the same layout your own uploads get, across the 14 vendor families we stitch into the attack graph: click any path to trace it hop by hop — foothold to crown jewel — every dollar labeled modeled, every hop declaring its evidence. Chains that cross vendors are a Program feature.
Every figure below is a count you can re-derive yourself — the checks re-run against your own uploaded file, the framework set is enumerable, the test suite is what our CI runs on every change. None of it is a usage stat, and none of it is borrowed.
Published up front, because there's no ambush waiting on a sales call. Four plans, every number visible — pick the job you're buying for. Every plan includes the architecture review, a new design with prices, a deployment plan product by product, and an upgrade roadmap. Designs, prices and upgrade picks are labeled modeled.
One intake in, one board-ready PDF out: three priced stacks, the architecture and deployment order of the Balanced one, a sequenced roadmap, your posture score and your modeled risk in dollars.
Upload a real config export and hand the auditor rule-by-rule findings — evidence excerpts and a written fix for each, plus the exact config change wherever the engine generates one.
One environment data set renders 12 board-ready reports — plus proof files anyone can re-check at /verify.
Program, on your infrastructure, with a human on the other end of the call.
White-label PDFs under your firm’s logo, custom internal control sets, and a single-tenant instance.
Global standards, US, Europe, and the GCC set most tools skip — SAMA, the NCA suite, PDPL, and DESC. Every framework you declare is scored control by control from the same profile and upload — no separate questionnaire, no second upload.
Coverage, not certification— we map your configuration to each framework's controls and score it. CyberTwin is not an accreditation body, and naming a framework here does not imply its issuer endorses us.
You hand over the exports you already have, and the engine turns them into structure, paths, prices, and proof. Four beats, told by the product itself.
A firewall config, an Okta export, a CSPM snapshot — files from your side of the wall. No agent to install, no credentials to hand over, no change window to book. One upload, and the engine has everything it needs.
The engine parses the real file and runs its vendor's deterministic checks — 1,913 across the catalog — and labels every result: proven when it's read from a FortiGate, PAN-OS or OPNsense config that re-parses into a re-checkable proof, observed when it's read from any other vendor's file, modeled when it's inferred. The grade travels with every number.
A finding alone is a to-do; chained, it is a breach. The engine stitches gaps across vendors into the paths an attacker could chain — foothold to crown jewel — and prices each one as modeled ALE at risk, with every hop declaring whether it is config-backed or assumed. The fix order defends itself.
Board pack, framework scores, audit evidence — every number dated to the upload it came from and re-checkable offline. When your configurations change, the next upload re-checks the claim — and for FortiGate, PAN-OS, and OPNsense configs, whose bytes re-parse, it re-runs the proof or shows exactly what broke.
A firewall config, an Okta export, a CSPM snapshot — files from your side of the wall. No agent to install, no credentials to hand over, no change window to book. One upload, and the engine has everything it needs.
The engine parses the real file and runs its vendor's deterministic checks — 1,913 across the catalog — and labels every result: proven when it's read from a FortiGate, PAN-OS or OPNsense config that re-parses into a re-checkable proof, observed when it's read from any other vendor's file, modeled when it's inferred. The grade travels with every number.
A finding alone is a to-do; chained, it is a breach. The engine stitches gaps across vendors into the paths an attacker could chain — foothold to crown jewel — and prices each one as modeled ALE at risk, with every hop declaring whether it is config-backed or assumed. The fix order defends itself.
Board pack, framework scores, audit evidence — every number dated to the upload it came from and re-checkable offline. When your configurations change, the next upload re-checks the claim — and for FortiGate, PAN-OS, and OPNsense configs, whose bytes re-parse, it re-runs the proof or shows exactly what broke.
Review the architecture you run and design the next one. Fix what matters most first. Then show your board and auditors where things stand, with every number labeled.
Start from the architecture you run: your trust zones, the paths an attacker could take to your crown jewels, and the order to fix them. Then design what comes next — three priced stacks with a deployment plan for the Balanced one, or a target design built from your requirements — and an upgrade roadmap with costs and lead times. Designs and dollars are labeled modeled; setup guides and configs are drafts your team reviews and applies.
Upload one config export and Configuration Review parses the real file and runs its vendor's slice of 1,913 deterministic checks. Every finding comes with a written fix — and wherever the engine writes the exact change (corrected CLI for most FortiGate findings, replacement snippets for many Palo Alto, Cisco ASA, Microsoft and CrowdStrike checks), it's ready to paste back in. When a CVE trends, type the ID and Breach Replay says whether it reaches you in the modeled twin.
A fix counts as closed only when your next upload confirms it — so your evidence stays current instead of a stale snapshot. Hand the auditor a dated bundle they can re-check themselves, offline.
Every modeled risk, config-review finding and severed attack path lands in one register — each with an owner and a dollar weight. Assign it, invite the people who fix it, and hand auditors a view-only proof they re-check themselves. The program runs in CyberTwin, not a spreadsheet.
Modeled risks, config-review findings and attack-path break-points land in a single register, each with an owner and a modeled dollar weight so the fix order defends itself.
Add colleagues by role, assign a finding to an owner, and track it to closed — the next upload re-checks whether the fix actually closed the path.
Hand an auditor or the board a view-only, re-verifiable snapshot — with view counts and one-click revoke. They re-check the signature themselves; nothing to trust.
illustrative preview · seeded demo estate · modeled dollars, not a real tenant
Five of the 12 board-ready reports your environment data set renders — real rendered pages from the seeded sample environment, not comps.
Each modeled path from an entry point to a crown jewel, its hops, the one change that breaks it, and its dollar exposure as a range · MODELED.
Your score across 24 frameworks with per-control provenance — each one labeled proven, observed or modeled.
The board-ready narrative: what changed, what it costs, what you decided — every tier, every quarter.
Twelve months of uploads condensed into the defensibility story — dated proofs, closed paths, scores over time.
Broker questionnaires answered from the engine with provenance chips — not from memory the night before renewal.
No customer logos yet — so instead of asking for trust, we show the grade on the work. A finding is proven, modeled, or honestly unknown, and you can tell which from across the room. The label decides what a number can survive.
Can an attacker reach the crown-jewel database — through identity, then the endpoint?
The same claim, drawn three ways.
re-parsed from the bytes of your uploaded config
inferred from typical topology — labeled, never hidden
a control we can't see from your upload — so we say so
A proven finding holds up under an auditor's challenge — it was re-parsed from your actual bytes. A modeled figure is decision support for sizing budgets. An honest-unknown is the gap we refuse to paper over. The label tells you which one you're holding.
The engine grades the stacks it recommends the same way — on the sample fintech company, Balanced 64/100, Advanced 72/100, both modeled from the declared stack, no upload consulted. See it graded →
Any proof bundle re-checks in your browser — nothing uploads. Verify a proof →
Pick Assess (from $499/month, cancel anytime), export a config, upload it, and get your findings, each read from your own file and naming the setting it comes from, the one change to make first, and what's at stake as a modeled dollar range. Attack-path mapping across your stack starts on Operate. No call required.
Assess and Operate bill monthly — cancel anytime. Your reports are PDFs; they work after you cancel.