For more than a decade, RPKI and Route Origin Validation (ROV) have helped reduce accidental prefix hijacks. Today, it is much harder for a network to incorrectly announce someone else’s address space without being detected.
But origin validation never answered a deeper question:
Is this AS path economically and topologically plausible?
That gap is what Autonomous System Provider Authorization — ASPA — is designed to close. And in early 2026, ASPA moved from standards discussions into operational availability: With ARIN announcing full ASPA availability in its January 2026 ARIN Online release, ASPA publishing is now production-ready in both the ARIN and RIPE NCC regions.
This is what ASPA is, why it exists, and why network engineers should start paying attention.
What ASPA actually does
ASPA is a new RPKI object type standardised through the Internet Engineering Task Force (IETF), specifically in the SIDROPS working group.
In simple terms, it allows an AS holder to declare:
“These ASNs are my authorised upstream providers.”
That declaration is cryptographically signed and published in RPKI.
Routers that consume validated RPKI data can then check whether the AS_PATH in BGP updates aligns with those declared customer–provider relationships.
If a path contradicts published ASPA data, it can be marked invalid.
Unlike BGPsec, which attempted full path cryptographic validation and saw limited deployment, ASPA takes a pragmatic approach. It does not attempt to sign every hop in the path. It validates only provider relationships, relying on long-standing “valley-free” routing assumptions.
That trade-off makes deployment realistic.
Why origin validation wasn’t enough
ROV solved a major problem: prefix hijacking.
But many of the most disruptive routing incidents in the past decade were not hijacks. They were route leaks.
In a route leak scenario:
- The origin AS is legitimate.
- The prefix is valid under RPKI.
- But the route is propagated through an unexpected provider chain.
From the perspective of origin validation, everything looks fine. From an economic and operational perspective, it is clearly wrong.
ASPA targets exactly this class of failure.
It allows networks to detect when a customer is announcing routes in ways that contradict declared upstream relationships — a strong signal of a leak.
How ASPA verification works in practice
Operationally, ASPA extends the same toolchain already used for RPKI:
- An AS publishes an ASPA object listing its upstream providers.
- RPKI validators fetch and validate the object.
- Routers receive validated ASPA payloads via the RPKI-to-router protocol.
- Routers perform AS_PATH verification locally.
No new cryptography is required inside the router.
Verification produces three possible states:
- Valid
- Invalid
- Unknown
The recommended deployment pattern mirrors early ROV:
- Reject invalid customer routes.
- Accept valid and unknown.
- Start with monitoring before enforcement.
Even partial deployment can detect a significant class of route leaks.
The long road to deployment
Work on ASPA began around 2019–2020 in the IETF, after years of analysis of route leak incidents. By 2022–2024, the object profile and verification procedures had matured through multiple draft iterations.
But standards are only half the story.
Operational adoption depends on three layers:
- RIR support for publishing objects
- Validator support
- Router implementation
On the RIR side, progress has been very recent:
In December 2025, the RIPE NCC integrated ASPA into its production RPKI Dashboard, making it available to operators across its service region.
And even more recently, in January 2026, ARIN announced:
“ARIN’s implementation of Autonomous System Provider Authorizations (ASPA) is now fully available in ARIN Online as part of the RPKI security features.”
Elsewhere, rollout timelines are becoming clearer.
APNIC has indicated that ASPA support is planned for deployment by the end of Q2 2026.
LACNIC has publicly committed to adding ASPA capability by the end of 2026 as part of its broader RPKI programme updates.
AFRINIC has also signalled intent to support ASPA within its evolving RPKI roadmap, though specific production timelines remain dependent on organisational developments.
At the software layer, ASPA object validation is supported in major relying-party implementations. Router-side path verification is available in Bird and OpenBGPD, with implementation and testing underway in Cisco IOS-XR. Wider vendor support is expected to follow operator demand.
We are still early, but the pieces are assembling fast.
Adoption still remains low
Despite the infrastructure now existing in key regions, ASPA adoption remains minimal.
Only a very small fraction of ASNs globally have published ASPA records as per February 2026: well under one percent of the global ASN space.
This is not unusual. ROV followed a similar trajectory: years of discussion, early cautious deployment, then gradual acceleration.
But ASPA’s value increases with participation.
The more ASNs that publish provider relationships, the stronger path validation becomes. With sparse coverage, many paths will simply fall into the “unknown” category.
ASPA’s effectiveness is directly tied to ecosystem participation.
Why opt to publish ASPA?
There is a subtle but important point here.
Even before you enforce ASPA validation on your routers, publishing accurate ASPA records contributes to global routing security.
Benefits of publishing ASPAs:
- You make it harder for malicious actors to fabricate plausible AS paths involving your ASN.
- You reduce the risk of your ASN being misused in leaked transit scenarios.
- You improve the quality of data available for path validation across the ecosystem.
- You prepare your network for future enforcement without rushing later.
Much like early ROA publication strengthened origin validation before universal enforcement, early ASPA publication strengthens the foundation for path validation.
Waiting until validation becomes widespread increases operational risk. Publishing early allows careful testing, monitoring, and correction.
Operational responsibility
ASPA is not “set and forget.”
When you publish an ASPA, you commit to maintaining an accurate list of upstream providers. If you omit one, ASPA-aware networks may mark routes via that provider as invalid once enforcement becomes common.
Complex relationships, including hybrid peer/provider arrangements and certain route server deployments, require careful review.
This is operational work. But it is work that aligns with the discipline already required for ROA management.
Final thoughts about the important shift to ASPA
ASPA does not change BGP.
It does not introduce heavy cryptographic overhead.
It does not require synchronised global deployment.
Instead, it encodes economic relationships into RPKI and allows routers to verify whether observed AS paths make sense.
With ARIN joining RIPE NCC in offering production ASPA publication, ASPA has crossed an important threshold.
Adoption is still low. Enforcement is still cautious. Vendor implementation is still maturing.
But the direction is clear: ROA-based origin validation became the norm because operators made it so. ASPA should be the next foundational layer of routing security — and its success depends on operators publishing now.
