Kazakhstan's ROA coverage nears 80%, while route validation lags

The RIPE NCC published a regional report on 17 September finding that Kazakhstan's IPv4 ROA coverage rose from around 13% in September 2025 to nearly 80% in September 2026. The same report records little corresponding change in route origin validation. For anyone announcing their own address space into or through the region, that gap is the part worth reading closely.

What changed

The report, written by RIPE NCC staff ahead of CAPIF 5 in Dushanbe on 24-25 September, attributes Kazakhstan's increase mainly to Kazakhtelecom creating ROAs for its IPv4 address space. A single large holder signing its resources moves a national percentage a long way.

Elsewhere in the region the picture is mixed:

Country	Reported position in September 2026
Kazakhstan	IPv4 ROA coverage near 80%, up from around 13%; little change in ROV; early ASPA progress
Uzbekistan	40 more ASNs and 80 more /24s than in 2025; modest ROA and ASPA gains; Uzbektelecom or its upstream has begun deploying ROV
Tajikistan	ROA coverage increased, with a particularly strong rise for government resources; ASPA adoption beginning to grow
Kyrgyzstan	Little movement overall; Uzbektelecom now among the five most central ASNs in its routing
Turkmenistan	Seven ASNs and 87 /24s of allocated IPv4 space; ROA coverage very high; ASPA and IPv6 adoption at zero

The report treats the Uzbektelecom development as the more consequential one for routing security, because that network is both the largest in Uzbekistan and among the most central in Kyrgyzstan's routing. Validation deployed at a central transit network protects the networks downstream of it, not only its own customers.

Coverage is not validation

Two different things are being measured, and conflating them overstates how protected a region's routing is.

A ROA is an authorization. It is a signed statement by the address holder naming the AS permitted to originate a prefix, and creating one changes nothing about how other networks forward traffic. Route origin validation is the enforcement step: a router compares a received announcement against RPKI data and can reject one found invalid, as described in RFC 6811. Our RPKI and ROA guide covers both halves in more detail.

High ROA coverage with low ROV deployment therefore means the region has published a lot of correct information that comparatively few routers are acting on. That is still progress, because the authorization data has to exist before anyone can validate against it. It is not the same as saying invalid announcements would be rejected there today.

A further caution on reading the figures: the report's findings come from RIPE Atlas traceroutes and RIPE RIS routing data, with ROV deployment drawn from RoVista and network centrality from the Internet Health Report. These are measurements from a set of vantage points, not a complete inventory of every route in the region.

Why it matters for BYOIP

If you bring your own prefix and announce it through a provider with a presence in these markets, the two halves fall on different sides of your control boundary.

The ROA is yours. You create it, you decide which AS may originate your prefix, and you are responsible for keeping it accurate when you change provider or region. Nothing in this report changes that obligation.

Validation belongs to everyone else. Whether a mis-origination of your prefix gets rejected depends on the transit providers and peers along each path, and national coverage statistics do not answer that question for any particular network. The practical reading is that a correct ROA is necessary but not sufficient, and that the protection it buys varies by the path traffic actually takes. See our BGP guide for how those path decisions get made.

What to check

• Confirm the ROAs for your own prefixes name the correct origin AS and maximum prefix length, particularly if you have changed provider since they were created.
• Ask prospective transit providers in the region whether they perform origin validation and what they do with an invalid result, rather than inferring it from a country-level figure.
• Treat measurement-derived adoption numbers as indicative. They describe what a set of vantage points observed, not a guarantee about any single route.
• Keep the distinction between authorization and validation in internal reporting, so a rising coverage statistic is not recorded as a reduction in hijack risk.
• If operating in the region, follow CAPIF 5 for the underlying analysis; RIPE NCC's measurement work is being presented there on 24 September.

Sources and further reading

The RIPE Labs report establishes the figures and the observation period. For background on how ROAs are created and what origin validation does with them, see our RPKI and ROA guide.