How long should an IP block last? Ageing out address based rules
Somebody adds an address to a deny list during an incident, and years later it is still there, in a rule set nobody has read since. The question everyone asks is how long a block should last. No standards body publishes a number, and the honest answer is not a duration at all: it is a review, because what decays is not the block but the match between the address and whatever you thought it was. Here is what the evidence actually supports, in both directions.
Why there is no number
Nobody authoritative publishes a recommended block duration. What the widely used documents publish is a review cadence: NIST SP 800-41 Revision 1, from September 2009 and still the current revision as of 19 August 2026, says it is important to review the firewall policy often and that such a review can uncover rules that are no longer needed as well as new policy requirements to add, while PCI DSS v4.0.1, released in June 2024, requires at requirement 1.2.7 that configurations of network security controls in an in-scope environment are reviewed at least once every six months to confirm they are relevant and effective. Neither says how long a block should last. One of the few places the reasoning is written down publicly is the English Wikipedia blocking policy as read on 19 August 2026, one volunteer community's written rules rather than an industry standard, which says addresses should rarely if ever be blocked indefinitely and gives the reason plainly, that a non-static address is likely to be reassigned or an open proxy likely to be closed, and that blocks on shared or dynamic addresses are typically shorter than blocks on registered accounts or static addresses, to limit side effects on other users. That reasoning is right, and it is the reasoning the measurement evidence supports, but it is one project's policy and not a rule anyone else has adopted.
How fast the ground actually moves
Two facts pull in opposite directions and you need both. The first: address space changes registered holder constantly. Counting the published registry transfer logs on 19 August 2026, calendar year 2025 carried 4,915 transfer records at ARIN, 7,279 at the RIPE NCC and 1,566 at APNIC, about 13,760 records, or roughly 38 a day, with 2024 in the same range at 15,093. Treat that as an upper bound: it covers three of the five registries, inter-registry moves can appear in both logs, and just under half of ARIN's 2025 records, 2,402 of 4,915, are typed as mergers and acquisitions, which change a holder's name without necessarily changing who operates the addresses (across the whole log since 2009 that type is 59 percent of records). Space that has moved before is over-represented among the movers: about 18 percent of ARIN's 2025 IPv4 records, 744 of 4,159, covered a range that had already appeared in an earlier record, and that is a floor, since matching on exact start and end addresses misses ranges split or re-aggregated between moves. The second fact is the corrective: those 2025 ARIN records covered roughly 8 percent of the IPv4 space ARIN lists as allocated or assigned, counting each record's range and so double counting space that moved twice, which leaves about 92 percent of it not appearing in a 2025 transfer record at all. An expiry timer applied across the board therefore produces no new information about most ranges while quietly reopening the ones that never moved. Underneath the registry layer, the operational picture moves faster and more quietly still, because leasing, sub-allocation and a new customer on an existing range change who is behind an address without producing a transfer record, and often without any visible registry change at all. The registry log is the wrong instrument for "is this still the same network"; it is only the loudest signal that the question is real.
The dates in the record will not tell you
The instinct is to age a rule against the block's registration date, and that instinct is wrong in a specific way worth knowing. Registry records are rewritten at transfer time rather than annotated, so the registration date can be the date of the most recent transfer rather than the age of the block. A concrete case: ARIN's log shows 167.17.0.0/19 transferring on 3 October 2025, and its RDAP record now shows a registration event at that same instant, while the log preserves the previous holder's source registration date of 1993. RDAP does define a transfer event action, but the transferred records we checked on 19 August 2026 exposed only registration and last changed, so a usable transfer date lives in the registry's transfer log rather than in the record itself. Inter-registry moves add a second trap for tooling: 168.222.0.0/16 left ARIN for the RIPE NCC in October 2025, so an enrichment pipeline pinned to one registry loses sight of a range entirely. And at the other end of the stack, the address may never have identified anyone: RFC 6269 states that where one public address is shared between subscribers it no longer uniquely identifies one, and warns in section 13.1 that one user failing a number of login attempts may block out other users behind the same address who have made no previous attempts, which is the whole argument against long blocks on carrier NAT space. Widening the rule does not rescue it either: the 2016 CAIDA and University of Maryland study Reasons Dynamic Addresses Change, which measured 3,038 RIPE Atlas probes during 2015, found that most of the ISPs it observed assigned around half of new addresses from a different announced prefix and that a third of observed address changes crossed a different /8, so escalating from one address to its enclosing block does not reliably track anything, and it multiplies whom you hit while it does so: the RFC 6269 point about one shared address applies many times over to a block widened to catch a single subscriber, where everyone else inside it loses service for something they had no part in; the probe population skews European and the data is now eleven years old. On the IPv6 side RFC 8981 sets default temporary address lifetimes of one day preferred and two days valid, so a rule against a single address can expire on its own before anyone reviews it.
What the blocklists do, and do not, expire
If you inherit rules built on public lists, their lifetimes are per list rather than a property of blocklists as a category, and the operators publish them unevenly. Within one operator's family, as published on 19 August 2026: the Combined Spam Sources listings generally expire about three days after the last detection, exploit listings expire automatically once the behaviour stops being detected with no duration published, the policy list describes ranges that should not send mail directly rather than bad addresses and expires the exclusion after a year rather than the listing itself, and the main blocklist documents no automatic expiry at all, with removal requested once the abuse has been terminated. UCEPROTECT publishes a different shape, as read the same day: a Level 1 listing expires automatically and free of charge seven days after the last spam mail from that address reaches its spamtraps, with an optional paid immediate removal, so the widely repeated claim that removal requires payment is wrong for Level 1. Its higher levels are a different instrument and should not be inherited without a decision: Level 2 lists the allocation around a listed address and Level 3 the whole of an ASN's space, on the strength of other senders' traffic, so a rule built on either blocks a large number of uninvolved networks for something none of them did. The sharpest lesson is what happens when a list stops existing: SORBS was decommissioned in June 2024 according to trade reporting of a statement by its owner, and its names no longer resolve, so a rule still querying it stops protecting anything. Do not leave the reference in place and watch it, because the quiet failure can flip: when a retired zone's domain lapses or changes hands the new holder can wildcard it so that every query answers yes, and mail servers have then rejected everything they received, as users of njabl.org found after that domain was picked up in 2024. Delete lookups for lists that have shut down, and alarm in both directions on the ones you keep: a source that has stopped returning hits, and a source that has started matching everything.
A review that works
Put the effort into the review rather than the timer. Where the enforcement point supports it, let short-lived automatic mitigations be automatic: a rate limiter with a mitigation timeout, or a jail with a default ban of minutes, expires without anyone deciding. Manual deny lists are the ones that need a calendar, because the documented fields of the common address list features carry no expiry or time to live: the AWS WAF IP set schema and Cloudflare's IP Access Rules documentation, both read on 19 August 2026, describe none, so nothing in the documented behaviour will remove an entry for you. When the review comes round, use the data you already have: the PAN-OS documentation, read on 19 August 2026, describes policy rule hit counts with first hit and last hit timestamps, and Panorama labelling rules used, partially used or unused where that setting is enabled, so a rule with no match in the review window is a candidate for removal whatever its age. The administration guide still lists renaming a rule alongside a manual reset as something that clears those counters, although rule usage has been tracked by UUID rather than by name since PAN-OS 9.0. Then for the entries that still match, ask the question the timer cannot: is this address still the thing you blocked? That is a lookup, not a guess. If the same network still announces the block and the registry record shows no change since the rule was written, age alone is not a reason to lift it. That holds for space one party operates end to end: an enterprise edge, a hosting allocation, a scanner's own range. It does not hold where the address is shared or handed out dynamically. On eyeball ISP, consumer broadband and carrier NAT space the registry entry and the announcing network can sit unchanged for years while the subscriber behind the address turns over many times, so those entries still need a finite expiry and a fresh reason to renew, not a reason to lift. If the origin changed, if the registry record now names a different organisation or carries dates you did not record, or if the space reads today as an eyeball ISP range full of ordinary customers rather than the hosting range you blocked, the rule is now pointed at somebody else, and that is a reason regardless of how recently it last matched. Hosting space is not a free pass in the other direction. One address there can front many unrelated tenants behind a shared server or an outbound NAT, and a range holds many unrelated customers, so the question at every width is the same one RFC 6269 asks about a shared address: how many uninvolved parties does this entry take with it? Cloud allowlists deserve the same scepticism in reverse, since a published range file changes constantly and does not include every service or any customer-brought space.
Re-run the address or block on the front page at review time and compare it with what you recorded when the rule was written: who holds it now and what the registry record says, whether it reads as hosting, eyeball ISP or proxy space, and which public blocklists the feeds still carry it on, remembering that an empty answer means no feed said so rather than clean. The routing history reaches back further than our own archive, so the network announcing the block at the date you wrote the rule can be read directly. The report names the source behind every field and says when each one was fetched, which is what turns a rule review from an argument into a diff.