Here is a finding from a network audit that has changed how I verify everything since.

A network running a public ASN with multiple transit providers and internet exchange presences had RPKI origin validation deployed the right way: a clean, templated policy applied uniformly on every transit and IX session across the fleet. Same structure everywhere, no snowflakes. Textbook.

Except on several of the transit edges, it validated nothing.

The gap between config and effect

RPKI origin validation has two halves. The routing policy on each router says “act on the validation state of received routes” (typically reject invalids, following RFC 6811 semantics). But the validation states themselves come from validator infrastructure: services that fetch and cryptographically verify the RPKI data published by the internet registries, then feed validated origin data to the routers over the RPKI-to-Router protocol.

On the affected edges, the policy was present and syntactically flawless, but the router had no healthy validator session feeding it. Without a validator feed, routes carry validation state “unknown,” the policy term evaluates against nothing meaningful, and it becomes a silent no-op. No error, no alarm, no log line. show commands confirm the policy is attached. It just does not do anything.

What likely happened is mundane: validators existed once, then a data center move and a couple of decommissionings quietly orphaned them, and one was never stood up at a newer site. Different sub-team owns the VMs than owns the router config; each side believed the picture was complete. The templated fairness of the policy actually made it more deceptive, because a spot-check on any router in the fleet would come back looking perfect.

Why this failure mode is so common

Almost all verification in network operations checks presence: is the config there, is the session up, did the template render, does the diff match the standard. Presence checks are cheap and automatable, which is exactly why they dominate. Compliance tooling loves them.

But security features have a nasty property: their failure mode is usually silence. A missing firewall rule drops nothing loudly. A dead validator feed rejects nothing loudly. The network keeps working perfectly, because the feature’s entire job was to act on rare bad events, and there is no user-facing symptom of it not acting. Availability failures page you; protection failures wait.

The only honest check is an effect check: not “is RPKI configured” but “is there at least one route on this router right now with validation state valid, and does a known-invalid prefix actually get rejected?” One question interrogates the config; the other interrogates reality.

The fix, and the checks that should have existed

The remediation was pleasingly small, which is part of what makes this story worth telling: point the affected routers at healthy validators (and stand up redundant ones per region, since a lone validator is its own quiet risk). No policy change needed anywhere, because the policy had been right all along. Days of work, not months, closing a gap that had silently sat on the edge for a long time.

The durable fix is monitoring shaped like the failure: validator session state as a paged alert, and a count of valid/invalid/unknown routes per edge as a tracked metric. If the “valid” count on a transit edge is zero, something upstream is lying to you, no matter what the config says. RPKI-invalid announcements are not hypothetical; origin leaks and hijacks circulate constantly, and dropping them is the whole point of MANRS-style routing hygiene. A no-op policy provides the compliance checkbox with none of the protection, which is arguably worse than nothing because it ends the conversation.

The generalizable rule

I now apply this test everywhere, and I credit this finding for it: for every protective control, ask what observable effect proves it is working right now, and monitor that, not the configuration. Config is a statement of intent. Effect is the only evidence the intent survived contact with infrastructure entropy: the moves, the migrations, the orphaned VMs, the sub-team boundaries.

Presence is what you audit. Effect is what protects you. The gap between the two is where this industry’s silent failures live.