For ISPs, IXPs, and network operators across Asia-Pacific who need routing security deployed properly, not just signed off on paper.
Not signed ROAs that nobody validates. Not a deployment that risks breaking your own routes. Not a consultant who leaves before your team can operate it independently. BGP was built for a cooperative network of known peers; the internet that exists today is neither, and RPKI is the cryptographic layer that closes the gap.
The Border Gateway Protocol was designed in 1989 for a network of cooperative, mutually trusting peers. On its own, it cannot confirm that the AS announcing a prefix is authorised to do so. RPKI adds that check. Without it, route hijacks and leaks can send traffic through networks it was never meant to cross, and a single misconfiguration can spread well beyond the network where it started.
The internet routes traffic based on assertions. RPKI turns assertions into cryptographic commitments. The technology is mature. The gap is deployment, not readiness.
Terry Sweetser, IEISIWithout route origin validation at upstream and peer routers, an AS announcing a prefix it doesn't own propagates globally. Traffic destined for your infrastructure, including customer data, authentication flows, and DNS queries, can be redirected through a network you don’t control.
A route leak occurs when an AS re-announces routes it should not propagate, typically customer routes re-advertised to other providers, creating unintended transit paths. It doesn't require malicious intent: a misconfigured policy on a routine change can affect millions of end-users before the first alert fires.
An ISP or IXP that accepts RPKI Invalid routes is one hop away from becoming unwitting transit for hijacked traffic. Your customers trust you to route their traffic only across paths with verifiable authorisation.
CISA, NIST, and the major RIRs (APNIC, ARIN, RIPE NCC) have all published routing security guidance that treats RPKI deployment as a baseline expectation. Boards and executives who haven't reviewed their organisation's RPKI status are carrying risk they may not have formally quantified.
Most operators weighing a routing security engagement are comparing it against one of these.
Reasonable if you genuinely haven't assessed the risk yet. Once a board or a customer asks the question, "we haven't looked into it" is a harder position to defend than a considered decision to wait, and the deployment doesn't get easier by delaying it.
Genuinely workable for straightforward ROA signing on a small, stable prefix set. The sequencing risk (max-length policy, signing before validating, checking coverage) is exactly where first-time deployments go wrong, and getting it wrong can break your own reachability.
Strong for a broad security review with heavy resourcing behind it. Routing security is a narrow, operational specialisation within that scope, and it's common for RPKI to end up as a paragraph in a larger report rather than a working, validating deployment.
RIR and vendor tooling keeps improving, and some of this genuinely gets easier over time. Validation still requires a deliberate decision on your network, and the deployment gap described above is a decision gap, not a tooling gap.
Routing security is not a single configuration change. It is a programme spanning registry hygiene, router policy, operational training, and governance. The sequencing matters: signing ROAs without validating routes leaves your customers exposed to others' invalid routes; validating without correct ROAs risks disrupting your own reachability. I have worked through this sequence across ISPs and carriers in Asia-Pacific and know where the operational surprises are.
Structured audit of your current posture: ROA coverage against announced prefixes, ROV status on peering and transit sessions, IRR record accuracy, and RIR registry hygiene. Produces a gap analysis and sequenced implementation plan, starting with the fixes that carry the highest risk if left unaddressed.
End-to-end Route Origin Authorisation signing for your APNIC, ARIN, RIPE NCC, or LACNIC allocated address space, covering both IPv4 and IPv6 prefix allocations. Covers max-length policy (a critical decision with operational consequences), ROA strategy for sub-delegation, and IRR cleanup that should accompany any ROA programme. Vendor-neutral across all RIR RPKI portals and hosted RPKI services. If you are also planning an IPv6 deployment →, ROA signing for your IPv6 space is part of that scope.
Router policy design and configuration to drop or deprioritise RPKI Invalid prefixes. Covers session-level policy, handling of NotFound prefixes, and the operational monitoring required to catch ROV-induced reachability issues before customers do. Supported on Cisco IOS/IOS-XR, Juniper Junos, MikroTik, BIRD, and FRRouting.
Autonomous System Provider Authorization is the next generation of BGP security, extending RPKI from origin validation to path validation and enabling detection of route leaks that ROAs alone cannot prevent. ASPA is in active IETF standardisation and early deployment. Advisory on ASPA object creation, provider relationship documentation, and readiness for networks preparing to deploy as standards finalise.
Practical routing security workshops for NOC and network engineering teams: RPKI architecture, ROA management workflows, ROV troubleshooting, IRR hygiene, and BGP security incident response. Designed for operators who maintain these systems in production, not for engineers sitting a certification exam. Delivered in-person across Asia-Pacific or remotely. See Training & Capacity Development → for the full training program.
Routing security policy documentation, board-level risk framing, and governance framework alignment (MANRS, NIST CSF, ISO 27001 Annex A). For management and boards who need to understand their organisation's routing security posture as part of broader cyber risk governance.
A structured audit of your current posture: ROA coverage against announced prefixes, ROV status on peering and transit sessions, IRR record accuracy, and RIR registry hygiene. You come out of it with a gap analysis and a sequenced implementation plan, whether or not you engage further.
A risk-ordered gap analysis and sequenced implementation plan you can act on immediately, in-house or with further support.
What typically follows: ROA implementation, route origin validation, ASPA preparation, operator training, and policy and governance work, scoped once the assessment findings are in hand.
Good cybersecurity is layered. At the network layer, that means RPKI. But the decision to deploy, and the accountability when it hasn't been, belongs at every level of an organisation: from the engineer handling ROA max-length policy to the board member approving the cyber risk register.
Boards routinely ask about ransomware preparedness and data breach liability. They should also be asking: does our AS have ROAs signed? Are we validating the routes we accept? The answers to those questions are a direct statement about whether we protect our customers' traffic.
Terry Sweetser, IEISIROA signing, route origin validation, RPKI cache configuration, BGP policy maintenance, and incident response. Routing security is operational technology: it requires the same change management rigour, monitoring, and runbook depth as any other production change. Training and implementation support for the teams who will own this day to day.
Routing incidents have caused outages at financial institutions, redirected customer authentication traffic, and generated regulatory scrutiny. For CISOs, CTOs, and operations leadership, the question is not whether RPKI matters, it is how to sequence deployment without disrupting production, and how to communicate the risk to boards who are not network engineers.
Cyber risk governance frameworks (ISO 27001, NIST CSF, Essential Eight) focus heavily on endpoint and application security. Routing security often falls through the gap. For boards overseeing ISPs, telcos, cloud providers, or any organisation with an AS number, RPKI deployment status is a legitimate governance question, and one that most cyber risk registers do not yet capture.
BGP security works better the more networks deploy it. A single AS validating routes is protected from invalid ones, but propagation of those routes upstream still affects the broader internet. Network Operators Groups across Asia-Pacific are the right venue to drive coordinated adoption, share operational experience, and build the peer pressure that moves industry norms faster than regulatory mandates ever will.
RPKI adoption in Asia-Pacific has grown substantially, but the work is not done. ROA coverage is uneven across the region, route origin validation remains a minority practice among smaller ISPs, and the operational knowledge to deploy and maintain RPKI correctly is not uniformly distributed. Through APNIC training programs delivered in person across 21 economies, and as Chair of the APNIC Routing Security SIG (2025 to 2027), I have seen directly where the gaps are and what barriers operators actually face.
Across Asia-Pacific, ROA registration has grown substantially, driven by RIR outreach, MANRS commitments, and peer pressure in the NOG community. But route origin validation, configuring routers to reject Invalid prefixes, lags well behind. Signing is the trust; validation is the verify. An RPKI ecosystem where many networks sign ROAs but few validate them provides limited actual security: hijacked prefixes can still propagate to networks that do not validate. The value of RPKI compounds as validation spreads, and every additional AS that validates makes the internet safer for everyone else.
Global figures from the IEISI RPKI audit (open data and code on GitHub), published September 2026. Sources: citations.
Reconcile announced prefixes against IRR records and RIR allocations. Fix stale, incorrect, or missing objects before signing ROAs against them.
Define max-length policy carefully. Overly permissive max-lengths undermine security; overly restrictive ones break traffic engineering. Get this right before signing.
Create ROAs for all announced prefixes via your RIR's RPKI portal or hosted RPKI service. Validate coverage with external tools (Cloudflare, RIPE Stat) before turning on validation.
Configure RPKI-RTR, validate cache connectivity, apply BGP policy to mark or drop Invalid prefixes. Start on a single upstream session; expand after confirming no reachability impact.
Operationalise: ROA expiry alerting, RPKI cache health monitoring, periodic prefix coverage reviews, and runbooks for handling ROV-induced reachability issues.
Yes, if your own ROAs are incorrect. This is the most common concern about ROV deployment, and it is also the most manageable risk. Before turning on validation, we validate that every prefix you announce has a correct, non-expired ROA with an appropriate max-length, and test in monitoring mode (marking Invalid prefixes without dropping them) before switching to drop them.
Most cyber risk frameworks focus on endpoint security, identity management, and application-layer controls. Routing security operates one layer below, at the network infrastructure level. A BGP hijack can redirect authentication flows, intercept unencrypted traffic, and cause denial of service without touching a single endpoint. RPKI, IRR hygiene, and MANRS conformance are the network-layer equivalents of patching, MFA, and access logging: hygiene controls that most organisations have not yet formally assessed or documented.
Brisbane, Queensland, with in-person experience delivering routing security training and advisory across 21 economies in Asia-Pacific through APNIC programs. Advisory work is available remotely across the region, with on-site presence where the scope warrants it.
Whether you are starting your RPKI programme, troubleshooting an ROV deployment, preparing a board briefing on routing risk, or wondering where to begin, start with a conversation. No sales cycle, no pitch deck.