Themis verified networking
Prove your network is segmented
the way you said it is.
Do you know which connectivity is legitimate, still needed, and actually enforced? Every network holds three truths: what you declared, what your kit enforces, and what actually flows. Themis holds all three against each other — continuously — and hands back the gap: what is running that nobody declared, what is allowed that nobody uses, and the dated proof for whoever asks next.
free read-only fixed scope ~30 minutes of exports no change window
Sample of the live verdict stream: flows are scored confirmed as they happen, until an undeclared flow — batch-runner reaching the cardholder database at 02:14 — is caught and escalated to a named human.
a job wakes up on your network.
It opens a connection to the card database. It has done this for three years.
No ticket describes it. No design doc mentions it. Nobody currently employed asked for it.
Four audits have passed since it started. It was already there, so nobody questioned it.
Themis names it on day one — and sends it to a person, with three years of history attached.
and it is never just one
Every estate has an 02:14 job.
Most have hundreds.
One intent — payments may reach the card database — ends up written as a rule on the edge firewall, an ACL on the core router, a VRF and a route-map, a security group in the cloud, and a policy in the cluster. Five places, five owners, and no single page where the answer is true.
That intent is a microsegmentation rule: this role may reach that role, on that port, nothing else. Writing it was never the hard part — every plane in the drawing can express it. Proving that all five still say the same thing, today, is.
Each one changed on its own schedule, in its own console, by its own team.
Nobody holds those five against each other. Every audit is an attempt to do it by hand, months late.
Do that for long enough and the drift stops being an anecdote about your estate. It becomes a statistic about everyone's.
69%
of firewall rules are unused FireMon Insights 2.0 · Jun 202645%
have no owner and no documentation Same dataset · 17% redundant or shadowed outright58%
of firewalls fail a high-severity compliance check Same dataset · 48% fail at critical severityIndustry baselines, not our results — 9.2m policy checks across hybrid networks. And all three are measured inside the firewall estate alone: one plane of the five. The first read-only pass measures yours, across all of them.
0200 what arrives, and when
Two weeks, free, from the first byte to a pack your auditor can replay.
Everything starts on day zero, because nothing forces a sequence: the engine scores at ingest. The clock starts at the first byte received — never at the signature.
- Day 0 One container in your tenant. Config exports pushed, flow exporters pointed at it. About thirty minutes of your effort, and nothing is written back.
- Day 5–7 The deterministic readout: declared against configured, every rule classified, the conservative retirement list. No flow needs to have been seen yet.
- Day 14 The full readout with whatever observed traffic accumulated, as a generated evidence pack — every claim linked to a hashed artifact.
- Continuously The window can keep running — that is Network Truth. Stopping it becomes a decision rather than a default.
0300 why a pass means anything
Anyone can generate a policy.
The question is who writes the exam.
Learn a policy from observed traffic and it scores perfectly — on the traffic it watched.
Then the failover runs. The 02:14 batch runs. Someone breaks glass at 3am. The flow that was never in the window gets dropped, in production, by the thing that was supposed to protect it.
So your own engineers write the exam. In week three your ops list the flows that must keep working — the quarterly failover, the batch window, the break-glass path — and seal the list. We never see it before the run, and the policy is scored against it before it goes anywhere near enforcement.
Every gate is shown going red on a seeded defect before you are asked to trust it. The separation is mechanical: the stage that drafts policy has no code path to the held-back data. And the audit itself replays byte-identically from its own frozen inputs — a third party who does not trust us runs it again and gets the same bytes.
0400 what you keep
The page you hand the auditor.
Not a dashboard nobody logs into. A dated artifact, generated from the platform's own history — the same one your customers' auditors keep asking you for.
the artifact
Segmentation evidence — scope: payments-prod
every decision carries user · time · event — approve, reject, retire
window digest sha256:9f2c…a41d · raw flows never left the site
Sample artifact, lab topology. Shape and fields are real; the numbers are not yours yet.
0500 the fit
Which of these is you?
Different pains, one first step: a free, read-only look at what is actually running, and the gap list in your hands two weeks later.
“The auditor wants proof of segmentation for a date. We have diagrams.”
You want dated evidence you did not rebuild by hand.
Themis generates it from what is actually configured and observed — and a third party can replay it from its own artifacts.
- Day 14: an evidence pack per scope, every claim linked to a hashed artifact.
- Then continuously: last Tuesday is a closed window, and a closed window replays.
- Read-only: nothing installed on a workload, nothing written to the network.
“Ten years of firewall rules. Nobody dares delete one.”
You want to retire rules without the 3am outage.
Every rule is classified — shadowed, redundant, unused per its own counters — and retirement is proposed only where the reachability model shows it is safe.
- Day 5–7: the classification and the conservative retirement list.
- Your change process applies; Themis verifies the change landed as intended.
- A named approver decides; the engine only proposes.
“Something reached something it should not have. We found out months later.”
You want drift to surface the day it happens, not at the next audit.
Declared against configured is recomputed on every change — exposure is found from configuration alone, before any flow. Seen-but-undeclared traffic escalates to a named human, never into the rule set.
- Six states, with the reason — not a hit count.
- Freshness is a gate with an alarm, not a dashboard tile.
- No SRv6, no agents, no write access. Estates stay here indefinitely.
“Every network change goes through a risk committee — and still breaks something.”
You want to know what a change touches before the window, not during it.
The network truth is computed from the configuration in force: dependencies, legitimate flows, unintended reachability — visible before the ticket, verified after it.
- The who-calls-who map and the reachability graph, from exports alone.
- After the change: proof it landed as intended.
- Nothing leaves your tenant. Deterministic, CPU only.
“We are starting a Zero Trust, segmentation or SRv6 programme and do not know where we stand.”
You want a measured baseline before committing the budget.
Value lands before transformation. The audit tells you what is worth doing; enforcement is earned on evidence it produces, never sold first.
- Two weeks, read-only, no change window.
- Savings computed from your own estate — never from our slides.
- Then segments that prove themselves — only where the estate pulls it.
e000 End.DT6 deliver
Start the free network audit.
Free, read-only, fixed scope. 30–60 minutes to agree the scope; then the clock starts at the first byte and you get the gap list two weeks later. Nothing is installed to have this conversation.
Prefer email? hello@th6mis.ai. Savings are computed from your own estate in the first two read-only weeks — never from our slides.