What an LOA is for IP address space, and what your upstream actually checks
A transit provider, colocation desk or cloud onboarding form asks you for an LOA before it will carry your prefix, and there is no standard to look up: neither of the two RFCs that bear on it defines the document, none of the registries we checked issues or validates one, and its whole authority rests on the reader believing the signature. Here is what the letter is, what the providers who publish their requirements actually ask for, who can sign it when the space is leased, and which records carry the weight the letter only claims. Every provider page cited below was read on 19 August 2026 and is quoted as it stood then; several carry no date of their own.
What the letter is, and is not
A letter of authorization for IP address space is a statement from the registered holder of a prefix saying that a named party may announce it, usually naming the prefixes and the originating AS number. That is the entire specification, because there is not one. We checked the two most relevant standards, RFC 7454 (BCP 194, the IETF's operational guidance on BGP security) and RFC 9323 (the RPKI object proposed as a replacement), and neither contains the phrase in any spelling. RFC 7454 instead says only customer prefixes should be accepted and all others discarded, and that validating those prefixes can be done with the appropriate IP address management authorities, which we read as the registries; it prescribes no document from the customer at all. No registry we checked fills the gap either: as of 19 August 2026 we found nothing at ARIN, RIPE NCC, APNIC, LACNIC or AFRINIC that issues, registers or validates a letter authorising a route announcement, and if one has launched such a service we would like to hear about it. ARIN goes further in the other direction, listing the leasing of IPv4 space using falsified letters of authority among the fraudulent activity it sees. So the honest framing is that the letter is a contractual artefact between the parties who sign it and an unauthenticated assertion to everyone else. It is not proof of holdership, and treating it as such is what the fraud exploits. That cuts both ways for the signer. A letter nobody can verify is still a letter somebody downstream will act on, and it carries no expiry unless you write one. Name the exact prefixes and the single announcing ASN, give it a start and an end date, say that it supersedes any earlier letter for the same space, and put in writing how you will withdraw it.
Two documents, one abbreviation
Before going further, separate the two things called an LOA, because the abbreviation does double duty at the carriers that publish anything. The routing letter travels from the customer to the carrier and says who may announce a prefix. The other is a data centre document, a letter of authorization with a Connecting Facility Assignment, and whichever side controls the port issues it: Cogent's customer user guide, which carries only a copyright year, has a service delivery specialist hand the customer an LOA and CFA so the customer can order cabling from a colocation vendor, while Arelion says that for services delivered to a data centre it requires a Letter of Authorization from the customer. Cogent uses the abbreviation exactly once in that guide and it is the cabling sense; Arelion publishes only the data centre sense, and its separate, undated routing security page asks for a matching route object and/or RPKI ROA naming the prefix, mask length and originating AS, mentioning no letter at all. If a ticket says "send us the LOA" and you are not sure which is meant, the room, panel and port numbers are the tell: the cross connect letter carries them and the routing letter does not.
What providers actually publish
Published requirements vary more than the folklore suggests. Cogent's BGP questionnaire (BGPQ-v8.0, dated 14 May 2026; an older v6.6 from December 2015 is still served at a second Cogent URL with the same clause) requires the customer ASN to be registered with the registry to the same company named on the Cogent contract, and asks for a letter from the owner of the registered resources only when it is not, which is the clearest statement we found that the letter exists to bridge a mismatch between the contracting entity and the registry record. Its customer user guide accepts announcements when the space carries a valid ROA or a route object in a trusted registry-run IRR, prefers those to generic ones and does not use ALTDB at all. Of the providers here, Cloudflare is the one that documents the letter in detail, calling it a Letter of Agency and noting the name Letter of Authorization is used for the same thing: it must be a PDF, should be on company letterhead with a wet signature, though the same page adds that Cloudflare accepts digital signatures as long as it is clear who is signing, and it must name the prefixes and the announcing ASN. AWS's published BYOIP process asks for no letter at any step, requiring instead proof that you control the range (a self signed certificate placed in the registry record where the registry supports RDAP, or, on its IPAM path, an AWS supplied token published as a TXT record in the reverse DNS zone for the prefix), a ROA authorising the Amazon ASNs, and an authorization message that is cryptographically signed rather than a document anyone signs by hand. OVHcloud is the same shape: a token it supplies, placed in the registry object, plus a route object matching the range exactly. Vultr, on its page last updated in September 2025, still asks you to upload a Letter of Authorization and supplies a template naming AS20473. Hurricane Electric publishes its filter as an algorithm driven by registry handles, IRR policy and RPKI validity, with no letter step in it; third party guides that say otherwise are not quoting AS6939. The pattern worth taking away is that the machine checks are increasingly what actually gets verified, while the letter survives wherever somebody downstream still expects one: Vultr asks for the letter and, in its separate onboarding material, for registry registration, a route object and a ROA as well. None of this changes who may authorise an announcement. Where a provider still takes a letter it expects it from the registered holder, or from someone the holder has visibly put in that position, so a letter signed by anyone else does not carry the authority it appears to. Some of those letters are the falsified ones ARIN describes. Others come from a reassigned customer, an agent signing for the holder, or a company whose registry record has not caught up with an acquisition. Treat the mismatch as unproven rather than as fraud, ask the holder to confirm it in the records, and note that filtering the prefix on a paperwork mismatch alone drops whoever is already behind it.
Who signs when the space is leased
This is where the document does real work and also where it is most often signed by the wrong party. Authority over a prefix sits with whoever the registry says holds it, and in practice with whoever controls the maintainer or organisation record: in the RIPE region an End User holds provider independent space while a sponsoring LIR or a direct contract carries the relationship with the RIPE NCC, and route object creation is gated by the maintainers on the covering address object and on the announcing aut-num, rather than by any letter. In the ARIN region the party is an Org ID, and only an account linked to an admin or tech contact on that Org ID can change it; note that a simple reassignment creates no relationship with ARIN at all, because ARIN does not recognise or engage with the organisation listed and the direct registrant keeps control of the record. The consequence for a lease is blunt. A lessee who is not the registered holder cannot create a ROA for the space, because only the party whose certification authority covers it can, so the two documented ways forward are the holder creating a ROA that names the lessee's announcing ASN, or the holder running a delegated certification authority and sub-delegating one to the lessee. Either way the ROA is a grant that outlives the deal unless somebody ends it. Set the maximum prefix length to the length actually being announced, or the lessee can validly originate every more specific inside the block, and delete or reissue the ROA when the lease ends, because one left behind makes the next announcement from that ASN look valid to everyone who checks. A letter signed by the lessee alone asserts an authority it does not have; a letter signed by the holder is worth exactly as much as the holder's willingness to also create the route object and the ROA that back it. If the holder will not do those, that is the finding, and it is a commercial conversation rather than a paperwork problem.
What is replacing it, slowly
The direction of travel is machine-checkable proof, but it is not finished, and the honest summary in August 2026 is that the letter survives as a contractual artefact while the records are what actually gets verified. RFC 9323 defines RPKI Signed Checklists, letting a resource holder sign a checksum of an arbitrary file with the number resources they hold, which is exactly the shape an LOA replacement would take. An Internet Society report from December 2025 lists only prototypes for signing one, and sets as its way forward enabling the registries to offer RSC generation and validation, which implies none did so as of that report, and we found no sign that has changed by 19 August 2026; we found no transit provider or cloud documenting that it accepts one, and the RIPE NCC's roadmap read on 19 August 2026 still lists the feature as planned, subject to team capacity. Meanwhile the older registry-side shortcut is gone: ARIN retired its Origin AS field on 28 July 2025, so the 2016 ARIN blog post recommending it for LOA validation, which now sits in ARIN's Vault under a notice that Vault content is never updated, describes a field that no longer exists. Cloudflare's self serve path shows where this lands in practice: the requester publishes route objects for the exact prefixes, places Cloudflare's validation token in either the IRR record or the reverse DNS for the range, whichever method it chooses, publishes accurate ROAs, and Cloudflare then generates the letter itself for the downstream networks that still want one. The paper does not vanish, and it has not stopped working either. It stops being decisive at the providers who publish a machine check, and it keeps all of its old force at the ones that ask for nothing else, which is where a forged letter still lands.
Look the prefix up on the front page before you sign or accept a letter: who the registry says holds the space and what the record says today, whether a ROA covers it and which AS it authorises, and which networks have announced it and when. A leftover origin AS from an earlier announcement, or a registered holder who does not match the company on the contract, is the discrepancy the letter is supposed to explain. Route objects live in the routing registries rather than in this report, so check those where you check the rest.