What is an Internet number resource audit?
An Internet number resource audit is a structured review of an organization’s IPv4 addresses, IPv6 addresses, Autonomous System Numbers, registry accounts, routing authorizations, supporting documents, and operational controls.
Table of Contents
ToggleThe purpose is to confirm that every resource:
– Is known to the organization
– Is associated with the correct legal entity
– Appears accurately in registry records
– Has a documented allocation, assignment, transfer, or usage basis
– Is routed only by authorized networks
– Has appropriate RPKI and IRR records
– Is protected by secure administrative access
– Is being used efficiently
– Complies with applicable policies and agreements
– Has a clear operational and commercial purpose
A strong audit connects technical data with legal, governance, security, and financial records. It should answer not only “Which IP addresses does the company use?” but also “Who controls them, why are they being used, who can change them, and what would happen if access were lost?”
Why companies should audit Internet number resources
Internet number resources often enter a business gradually.
A company may receive an IPv4 allocation from a Regional Internet Registry, obtain provider-assigned space, acquire a business with existing resources, lease addresses for a cloud deployment, or use multiple ASNs across different subsidiaries.
Over time, records can become fragmented.
Common problems include:
– Resources registered to an old corporate entity
– Former employees remaining as registry contacts
– Unknown or undocumented BGP announcements
– Inaccurate WHOIS or RDAP information
– Missing or outdated Route Origin Authorizations
– Stale Internet Routing Registry objects
– Unused IPv4 space
– Overlapping internal assignments
– Expired Letters of Authorization
– Incomplete transfer documentation
– Unmonitored registry-policy changes
– Resources used by third parties without current agreements
These issues can affect network continuity, cybersecurity, regulatory compliance, transferability, and asset value.
NRS has previously examined how poor IP address management can damage enterprise value. The central lesson is that incomplete inventories and weak controls create costs far beyond the network team. They can contribute to outages, security gaps, wasted resources, delayed transactions, and governance risk.
What should be included in the audit?
A complete audit should cover all Internet number resources and the systems that support them.
| Audit area | What should be reviewed |
|---|---|
| IPv4 resources | Allocations, assignments, transfers, leases, utilization, and routing |
| IPv6 resources | Allocations, addressing plans, routing, adoption, and security |
| ASNs | Ownership, use, BGP peers, route origins, and access controls |
| Registry accounts | Legal entity, users, contacts, authentication, and membership status |
| Documentation | Allocation records, agreements, transfers, leases, LOAs, and corporate history |
| Routing | BGP origins, upstreams, route visibility, route leaks, and unauthorized announcements |
| RPKI | ROAs, origin ASNs, maximum prefix lengths, validity, and monitoring |
| IRR | route, route6, and aut-num objects |
| DNS | Reverse-DNS authority, nameservers, and operational contacts |
| Security | Account access, multifactor authentication, logging, and incident response |
| Reputation | Abuse history, blocklists, geolocation, and customer use |
| Governance | Applicable RIR policies, agreements, fees, and reporting responsibilities |
| Business use | Critical services, customers, revenue dependency, and continuity plans |
Step 1: Define the audit scope and ownership
The first step is to identify who is responsible for the audit.
Internet number resources cross several business functions, so the review should not be assigned only to a network engineer.
Relevant participants may include:
– Network operations
– Information security
– Legal counsel
– Compliance
– Finance
– Procurement
– Corporate administration
– Risk management
– Mergers and acquisitions
– Executive leadership
One person should act as the audit owner. That person should coordinate evidence, deadlines, findings, and remediation.
The audit scope should cover:
– Every corporate entity
– All business units
– Current and former company names
– Acquired or merged organizations
– Cloud and hosting environments
– Regional offices
– Data centres
– Managed service providers
– Subsidiaries and joint ventures
– Leased-in and leased-out resources
– Provider-assigned address space
The audit should also define a review date. Routing and registry records change, so findings must be tied to a specific point in time.
Step 2: Build a complete resource inventory
Create a central inventory of all IPv4 prefixes, IPv6 prefixes, and ASNs used or controlled by the organization.
Information can be collected from:
– RIR accounts
– RDAP and WHOIS records
– IP address management systems
– Router configurations
– BGP monitoring systems
– Cloud accounts
– Firewall rules
– DNS records
– Transit-provider records
– Colocation providers
– Previous invoices
– Allocation and transfer documents
– Lease agreements
– Merger and acquisition files
– Internal spreadsheets
– Procurement records
For every resource, record:
– Prefix or ASN
– Resource type
– Current RIR
– Registered organization
– Internal owner
– Operational contact
– Allocation or transfer date
– Source of the resource
– Current usage
– Origin ASN
– Upstream providers
– RPKI status
– IRR status
– Reverse-DNS authority
– Lease or contract status
– Business criticality
– Supporting document location
Do not assume that the registry account contains the complete inventory. Provider-assigned, leased, or inherited resources may appear elsewhere.
Step 3: Confirm the relevant RIR and registry status
The global Internet number resource system is coordinated through five Regional Internet Registries:
– ARIN
– RIPE NCC
– APNIC
– AFRINIC
– LACNIC
The Number Resource Organization provides an overview of the RIR system and the regions served by each registry.
For each resource, confirm:
– Which RIR administers it
– The registered organization
– Resource status
– Allocation or assignment type
– Registration date
– Available transfer history
– Administrative contacts
– Technical contacts
– Abuse contacts
– Membership or contractual status
– Outstanding fees or administrative issues
Use the authoritative RIR service rather than relying entirely on commercial lookup tools.
RDAP is the modern standardized protocol for accessing registration information. Its query format is defined in RFC 9082, and its response format is defined in RFC 9083.
Save a dated copy of the official record as audit evidence.
Step 4: Verify the legal entity and chain of records
The organization using the resource may not be the same legal entity shown in the registry.
This can happen after:
– A company-name change
– A merger or acquisition
– A restructuring
– Creation of a new subsidiary
– Movement of operations between group companies
– Dissolution of an older entity
– A transfer that was not fully reflected internally
– Use of a former trading name
For every resource, compare the registry record with:
– Certificates of incorporation
– Company-name change records
– Merger documents
– Acquisition agreements
– Transfer approvals
– Registry agreements
– Board resolutions
– Invoices
– Lease contracts
– Letters of Authorization
– Historical correspondence
The goal is to create a clear documentary chain connecting the original registration or allocation with the organization currently claiming or exercising control.
If the chain is incomplete, record the gap rather than assuming long-term use has resolved it.
NRS’s guide to protecting IP assets from governance risk explains why accurate records, complete documentation, policy awareness, and legal structure are important to resource continuity.
Step 5: Review registry-account security
A company may have complete documentation but still face risk if its registry account is poorly secured.
Review:
– All active users
– User roles and privileges
– Shared accounts
– Multifactor authentication
– Password and recovery policies
– API credentials
– Authorized email domains
– Recovery telephone numbers
– Third-party access
– Former employees
– Consultants and service providers
– Login and change logs
– Emergency recovery procedures
Recommended controls include:
– Individual named accounts
– Least-privilege access
– Phishing-resistant multifactor authentication
– Dual approval for sensitive changes
– Quarterly access reviews
– Immediate removal of departed staff
– Secure storage of recovery information
– Independent logging of important changes
– A tested account-recovery process
Registry access should be treated like access to other critical business systems.
Step 6: Audit BGP route origins
For every public prefix, identify which ASN currently originates it.
Compare the result with:
– The company’s intended network design
– Router configurations
– Transit agreements
– Letters of Authorization
– RPKI ROAs
– IRR route objects
– Cloud or hosting arrangements
– Lease agreements
Investigate:
– Unknown origin ASNs
– Multiple-origin prefixes
– Unexpected more-specific announcements
– Routes visible only in some regions
– Prefixes that should be announced but are not
– Announcements continuing after a service ended
– Resources routed through former providers
– Unapproved third-party use
A multiple-origin prefix is not automatically incorrect. Multihoming, migration, distributed infrastructure, and security services may create legitimate cases. The audit should determine whether each origin is understood and authorized.
Step 7: Audit RPKI and ROAs
Resource Public Key Infrastructure helps networks verify whether an ASN is authorized to originate a prefix.
A Route Origin Authorization contains:
– An authorized ASN
– One or more IP prefixes
– An optional maximum prefix length
The current technical standard for ROAs is [IETF RFC 9582]
For every routed prefix, check:
– Whether a ROA exists
– Whether the origin ASN is correct
– Whether the prefix matches the announcement
– Whether `maxLength` is appropriate
– Whether the route is valid, invalid, or not found
– Whether old ASNs remain authorized
– Whether planned migration ASNs are covered
– Whether monitoring is enabled
– Who can create, change, or remove ROAs
An overly broad `maxLength` may authorize more-specific announcements beyond the organization’s actual needs. An overly restrictive value can cause legitimate routes to become RPKI invalid.
ROA changes should follow a controlled process. During a migration, the new authorization should normally be established and validated before the old route is withdrawn or its ROA removed.
Step 8: Audit IRR objects
Internet Routing Registries allow operators to publish routing-policy information.
Relevant objects may include:
– `route`
– `route6`
– `aut-num`
– `as-set`
– `mntner`
For each resource, determine:
– Which IRR contains the object
– Whether the prefix is correct
– Whether the origin ASN is correct
– Whether duplicate or conflicting objects exist
– Whether old provider objects remain
– Which maintainer controls the object
– Whether access credentials are secure
– Whether the record matches RPKI and live BGP data
Stale IRR records can cause routing-filter problems. Some networks generate filters from IRR data, so incorrect objects may contribute to legitimate routes being rejected or unauthorized routes being accepted.
The audit should not assume that an existing IRR object is accurate simply because it has existed for many years.
Step 9: Review Letters of Authorization
A Letter of Authorization may permit a provider or specified ASN to announce an IPv4 prefix.
Create an inventory of every current LOA and record:
– The covered prefix
– The authorized organization
– The authorized ASN
– The purpose
– The issue date
– The expiry date
– The signatory
– The related contract
– The revocation process
– Whether the authorization remains necessary
Look for:
– Expired LOAs
– Documents issued by former employees
– Incorrect ASNs
– Authorization granted to former providers
– Open-ended permissions
– LOAs inconsistent with current RPKI
– Missing documents for active third-party announcements
An LOA is commercial or operational evidence. It is not a substitute for cryptographic route-origin validation or accurate registry records.
Step 10: Review leases and third-party use
The company may lease addresses from another organization or allow third parties to use its resources.
For every arrangement, verify:
– Contracting parties
– Prefixes
– Start and end dates
– Permitted uses
– Origin ASN
– Geographic deployment
– Customer identity
– Abuse-handling responsibilities
– RPKI responsibilities
– IRR responsibilities
– Reverse-DNS control
– Geolocation management
– Renewal conditions
– Termination procedures
– Return or renumbering requirements
The technical deployment should match the commercial agreement.
If an agreement has ended, confirm that:
– BGP announcements have stopped
– LOAs have been revoked
– IRR objects have been updated
– ROAs have been changed where required
– Reverse-DNS access has been removed
– Customer assignments have been closed
– Internal records have been updated
Step 11: Measure resource utilization
The audit should determine how much address space is actively used and how efficiently it is allocated.
For IPv4 resources, classify addresses as:
– Assigned and active
– Reserved
– Infrastructure
– Customer allocated
– Quarantined
– Available
– Unknown
– Unreachable
– Under migration
– Held for documented growth
Utilization should be measured carefully. A lack of observed traffic does not always mean an address is unused. Some addresses support standby systems, disaster recovery, allowlists, low-volume infrastructure, or customer commitments.
Review:
– Oversized subnets
– Abandoned projects
– Former customer assignments
– Duplicate reservations
– Fragmentation
– Unused public addresses assigned to internal-only systems
– Inconsistent records between IPAM and live configuration
– Capacity forecasts
NRS’s discussion of IP address management and centralized governance risks provides further context on why accurate administration and resilient controls matter.
Step 12: Audit IPv6 separately
IPv6 should not be treated as an appendix to the IPv4 audit.
Review:
– Allocated IPv6 prefixes
– Addressing plans
– Current announcements
– ROAs
– IRR objects
– Reverse DNS
– Firewall policies
– Neighbor Discovery protections
– Cloud security groups
– Monitoring coverage
– Customer assignments
– Unused legacy designs
– Documentation and staff knowledge
A network may have secure IPv4 controls but weak IPv6 visibility. This creates risk because operating systems and cloud platforms may enable IPv6 even when the organization does not actively manage it.
Confirm whether IPv6 is:
– Fully deployed
– Partially deployed
– Used only internally
– Enabled unintentionally
– Planned but not active
– Disabled under a documented policy
Step 13: Review reverse DNS and geolocation
For each public prefix, confirm:
– Who controls reverse-DNS delegation
– Which nameservers are authoritative
– Whether required PTR records exist
– Whether old providers retain access
– Whether email-related records are correct
– Whether DNS changes are logged
– Whether geolocation reflects actual deployment
– Whether geofeed information is available and accurate
Incorrect reverse DNS may affect email delivery, troubleshooting, security analysis, and customer applications.
Incorrect geolocation can affect content access, fraud controls, regional services, advertising, analytics, and compliance workflows.
Step 14: Review reputation and abuse history
IPv4 resources carry operational history.
Audit:
– Major reputation and blocklist results
– Abuse complaints
– Spam history
– Malware reports
– Scanning activity
– Fraud-related reports
– Customer incident records
– Remediation activity
– Address quarantine procedures
– Abuse contact accuracy
– Response times
A listing does not automatically mean a prefix is unusable. Some records may be outdated, disputed, or related to a previous user.
Each finding should be assessed according to:
– Source
– Date
– Evidence
– Current use
– Business impact
– Remediation options
The organization should also review how new customers are assessed before receiving address space.
Step 15: Review RIR policies and agreements
Internet number resources operate within policies and service arrangements that may change over time.
For each relevant RIR, review:
– Membership status
– Applicable agreements
– Current fees
– Transfer policies
– Contact-validation requirements
– Resource-review procedures
– Legacy-resource treatment
– RPKI terms
– Reporting duties
– Policy proposals affecting the company
The audit should distinguish between:
– Formal policy
– Contractual obligations
– Operational procedures
– Guidance
– Proposed changes
– Community discussion
NRS provides members with Internet policy updates, training, and opportunities to participate in number-resource policy discussions. Organizations can review [NRS membership options](https://nrs.help/Membership/) and the [NRS frequently asked questions](https://nrs.help/faq/) for more information.
Step 16: Assign a business criticality rating
Not every prefix carries the same operational risk.
Assign a criticality level based on factors such as:
– Number of customers
– Revenue dependency
– Difficulty of renumbering
– Use in security allowlists
– Email reputation
– Partner integrations
– Cloud or hosting dependency
– Regulatory importance
– Availability of replacement capacity
– Expected recovery time
A useful classification might include:
– **Critical:** Loss would cause major customer, revenue, or security impact.
– **High:** Loss would disrupt important services and require difficult remediation.
– **Moderate:** Replacement is possible with planned engineering work.
– **Low:** Resource is temporary, unused, or easily replaced.
Critical resources should receive stronger monitoring, access control, documentation, renewal management, and continuity planning.
Step 17: Document findings and remediation
Every finding should include:
– Affected resource
– Description
– Evidence
– Risk category
– Business impact
– Responsible owner
– Required action
– Due date
– Verification method
– Current status
A practical priority model is:
| Priority | Meaning | Example |
|---|---|---|
| Critical | Immediate continuity or security risk | An unknown ASN is originating a company prefix |
| High | Serious control or compliance weakness | A former employee retains registry access |
| Medium | Important inconsistency requiring correction | An outdated IRR object remains active |
| Low | Documentation or optimization improvement | An internal resource description is missing |
| Observation | No current defect, but future attention is needed | Available capacity is approaching a defined threshold |
The audit is complete only when material findings have owners and remediation dates.
Internet number resource audit checklist
Inventory
– Have all IPv4, IPv6, and ASN resources been identified?
– Are provider-assigned and leased resources included?
– Are acquired and legacy entities covered?
– Does every resource have an internal owner?
Registry
– Is the correct legal entity shown?
– Are contacts current?
– Is membership status clear?
– Are fees and agreements up to date?
– Have authoritative records been archived?
Documentation
– Are allocation and transfer documents available?
– Is the corporate chain complete?
– Are contracts, leases, and LOAs current?
– Is every third-party use documented?
Routing
– Is each origin ASN understood?
– Are unexpected origins investigated?
– Are obsolete announcements removed?
– Are more-specific prefixes authorized?
RPKI and IRR
– Are ROAs correct?
– Is `maxLength` appropriate?
– Are routes RPKI valid?
– Are IRR objects accurate?
– Are old maintainers removed?
Security
– Is multifactor authentication enabled?
– Are shared accounts eliminated?
– Are former staff removed?
– Are changes logged?
– Has account recovery been tested?
Operations
– Is utilization measured?
– Is reverse DNS accurate?
– Is geolocation reviewed?
– Are reputation findings managed?
– Is IPv6 included?
Governance and continuity
– Are policy changes monitored?
– Has business criticality been assigned?
– Is replacement capacity available?
– Is there an incident-response plan?
– Are audit findings tracked to closure?
How often should the audit be performed?
A complete audit should generally be performed at least once a year.
Critical records should be monitored continuously or reviewed more frequently.
Additional audits should follow:
– A merger or acquisition
– A corporate-name change
– A network migration
– A major cloud deployment
– A transfer or lease transaction
– A security incident
– A registry-account access problem
– Departure of key network staff
– A significant RIR policy change
– Discovery of an unauthorized route
– Preparation for financing or sale
The audit should also become part of normal due diligence for any transaction involving Internet infrastructure.
Final takeaway
An Internet number resource audit is not simply a list of IP addresses.
It is a review of the company’s network identity, registry position, routing authority, documentation, security controls, operational use, and continuity exposure.
A reliable audit answers five fundamental questions:
1. What resources does the company have?
2. Which legal entity and registry records support them?
3. Who can administer and announce them?
4. Are the records, routing, RPKI, and contracts aligned?
5. Can the business maintain continuity if something changes?
When those questions are answered clearly, Internet number resources become easier to protect, manage, transfer, and use responsibly.
Organizations seeking greater awareness of number-resource policy and governance can explore NRS membership or contact NRS for more information.
Frequent Asked Questions
Number resources are the identifiers that allow networks and services to operate on the Internet. They include public IP addresses and Autonomous System Numbers. Infrastructure operators use these resources for routing, customer access, hosting, security controls, partner integrations, and service delivery.
Number resources need a continuity plan because instability can affect customer access, partner connections, firewall allowlists, routing, compliance workflows, and revenue-generating services. Even when servers and applications are still online, customers may experience disruption if the underlying number resources are no longer stable or trusted.
If IP address continuity is not protected, operators may face service disruption, customer complaints, failed integrations, security blocks, migration pressure, reputation issues, and revenue loss. Customers may also need to update DNS records, firewalls, VPNs, payment systems, or partner allowlists, which can create additional operational burden.
Number resource continuity should involve network, legal, commercial, finance, compliance, and customer operations teams. Network teams may manage routing and technical configuration, but contracts, renewals, customer commitments, and business impact require cross-functional ownership.
Operators should review their number resource continuity plans regularly and before any major renewal, customer migration, network expansion, provider change, or IP leasing agreement update. Reviews should also happen after incidents, ownership changes, registry updates, or changes to critical customer services.

