RPKI vs social engineering: How to protect your BGP when the human firewall fails
In 2025, a Latin American ISP suffered BGP route hijacking that lasted almost 40 minutes. The curious—and worrying—part is that the provider had RPKI implemented. It had published its ROAs. Its filters were in order.
What it lacked was a secure onboarding process for new BGP customers.
This is the case APNIC documented on its blog in late March 2026, and it is required reading for any team running BGP sessions in Latin America.
What exactly happened?
An attacker posed as a legitimate new BGP transit customer. They went through the provider’s onboarding process, obtained valid credentials, and began announcing prefixes that were not theirs. Because the provider did not properly validate the customer’s identity or the true origin of their prefixes during provisioning, the announcements passed initial filters.
RPKI was there. ROAs existed. But the attacker never needed to break RPKI: they exploited the gap between the human process and the technical system.
The real problem: RPKI protects the path, not the process
RPKI (Resource Public Key Infrastructure) is today our strongest tool to validate that whoever announces a prefix is authorized to do so. When implemented correctly, routers practicing Origin Validation reject INVALID ROAs.
But RPKI validates the technical authorization of an AS to announce a prefix. It does not validate that the person who configured that BGP session on your router is who they claim to be.
That distinction, seemingly obvious, is exactly the vector the documented attack exploited.
Three steps to close the loop
1. Out-of-band identity validation in onboarding
Every new BGP peer or customer onboarding should include out-of-band identity checks: confirmation via separate channels (verified corporate email, video call, phone call to a number registered with the relevant RIR). A web form alone is not enough.
2. Correlation between declared AS and RIR records
Before activating any BGP session, verify that:
- The AS number declared by the customer is registered with LACNIC, ARIN, RIPE, or the appropriate RIR
- The technical contact in the registry matches whoever is doing onboarding
- Prefixes the customer will announce have ROAs created before go-live (not after)
3. Grace period with monitored-only
In the first days of a new BGP session, configure the peer in monitored-only mode: announcements are received and logged but not propagated until the NOC team reviews them manually. Minimal operational friction, high security return.
RPKI status in Latin America
According to LACNIC data from 2025, RPKI adoption in the region keeps growing, but Route Origin Validation (ROV) on provider routers remains uneven. Many ISPs have ROAs but do not actively practice ROV, meaning that even with partial RPKI deployment, an invalid announcement can still propagate.
The RPKI adoption map in Latin America shows strong progress in Brazil, Argentina, and Colombia, but significant gaps elsewhere in the region.
What Ayuda.LA can do for your network
At Ayuda.LA we work with ISPs and highly connected enterprises on routing security implementation and audits:
- BGP audits: we review filter configuration, ROAs, and routing policies to find gaps before an attacker does
- End-to-end RPKI implementation: from ROA creation to enabling ROV on your edge routers
- Secure onboarding design: we help you build BGP customer provisioning that combines technical validation with human verification
If your network runs BGP sessions and you have not audited your onboarding process yet, now is the time.
Want to know how your network is configured against this class of attacks? Contact our team for a BGP routing audit.
References: