Summary

  • RIPE NCC reported revoking 35 delegated RPKI certification authorities that remained non-functional after warnings and a final repair window. The policy trigger is a long failure to discover and validate a current Manifest and Certificate Revocation List, not a short interruption or a route announcement.
  • The NRO’s October 2026 comparison lists a 90-day threshold for RIPE NCC and 60 days for APNIC. These are regional rules for a specific delegated-CA failure state, not a single global RPKI standard.
  • The useful operational record is a clock with evidence: the last valid publication data, monitoring results, notices, operator response and the certificate’s eventual state. A revoked CA may be recreated, but the original certificate state cannot be rewound.

Thirty-five revocations make the clock concrete

The update is unusually specific. In a 24 September message to RIPE’s Routing Working Group, RIPE NCC said it had begun tracking non-functional delegated CAs on 9 June. It sent warnings to users associated with its first batch on 14 September, gave them another week to repair their systems, then revoked 35 CAs that were still non-functional. The announcement is an operator report, not an independent census of every inactive CA in the region.

For later cases, RIPE NCC described a repeatable sequence: registered users receive notifications after 7, 30 and 60 days; if the CA remains non-functional after 90 days, its certificate is revoked. The RPKI Dashboard has also been updated with more diagnostic information. That schedule turns a broad policy into a sequence that an operator can monitor and act on.

What the 90-day test measures

RIPE-847 defines the trigger narrowly. If RIPE NCC cannot discover and validate a delegated CA’s current Manifest and Certificate Revocation List (CRL) for more than three months, the CA’s resource certificate must be revoked. The policy calls for reasonable efforts to discover new Manifests and to notify the operator when current data cannot be validated and when revocation occurs.

A Manifest describes the signed objects a certificate authority publishes; a CRL records certificates that have been revoked. A validator needs current, verifiable publication data to use that delegated branch of the resource PKI. “Non-functional” here does not mean that every path must work perfectly at every moment. RIPE’s policy rationale distinguishes a persistently stale or unreachable publication point from a partial transport problem where a current Manifest can still be found and validated.

That distinction matters because a long clock is not a general outage timer. It is a cleanup rule for a particular CA state. RIPE’s analysis says that after months without a current Manifest and CRL, the objects are already stale; it does not claim that revocation will improve route security or that the first day of a service interruption immediately invalidates every route authorization. The materials reviewed here do not quantify validator savings or show a change in route acceptance.

One comparison, two regional thresholds

The Number Resource Organization’s 2026-Q3 Comparative Policy Overview, published on 9 October, places the two rules beside each other: 90 days for RIPE NCC and 60 for APNIC. Its PDF explicitly describes itself as a reference, not a policy statement, and warns that it can be outdated by later implementation. The underlying regional policies and current service status remain the authority.

APNIC’s prop-166 also targets a persistently non-functional delegated, or self-hosted, CA whose current Manifest or CRL cannot be discovered and validated. Its impact analysis uses 60 days because calendar months vary. The proposal reached consensus at APNIC 60 and was endorsed by the Executive Council in December 2025; APNIC 61 materials later marked technical implementation complete. RIPE’s separate accepted policy uses three months, operationalized as 90 days.

The gap is not a contradiction. Both systems define a stale delegated-CA condition, but their policy processes chose different clocks. Nor does the comparison make either one a universal setting for every RIR, every hosted CA or every publication failure. NRO provides a compact map; APNIC and RIPE NCC provide the operative details.

Notification is part of the control surface

The thresholds are only useful if the monitoring record is explainable to the resource holder. A system should be able to show which Manifest and CRL it last validated, when it first failed to validate current data, which contacts received notices, and whether the operator repaired, migrated or voluntarily revoked the CA. Without those timestamps, “90 days non-functional” can hide whether the measured problem was the CA, a discovery route, a stale contact address or an incomplete observation.

The notification intervals also create an intervention window. An operator has time to restore publication, confirm that the parent can discover it, or decide that a delegated CA is no longer needed. The RIPE announcement says the CA can be recreated through normal Dashboard setup after revocation. That is a recovery path, not a reversal of the original certificate’s revocation record.

Heng Lu’s Note 70 offers an editorial lens rather than evidence about these rules: protect continuity of the registry function while asking precisely which authority is being exercised. Here the specific control is narrower than an institutional claim. It is a published policy trigger, a monitored period, a notice process and a certificate-state change. Its credibility depends on making each step reviewable.

What network operators should track

An operator using delegated RPKI should know which clock applies to its parent RIR and deployment model. A practical record includes the CA’s owner and current contacts; last successful Manifest and CRL validation; the first failed validation; notice delivery and response dates; and the final status. Where a notice arrives, the useful question is whether the CA can publish verifiable current data—not simply whether a web page or one transport endpoint responds.

If publication has been abandoned, voluntary revocation may be preferable to waiting for a parent action. If the CA still matters, the operator should repair and validate the publication path early enough for the parent’s monitoring to observe it. The 60- and 90-day periods are not a grace period for leaving a critical publication point unattended; they are outer policy thresholds for a persistently broken state.

The decision beneath the timer

The policy distributes costs. A dormant CA can consume repeated validator fetches and produce stale-state noise; removing it gives relying parties one less persistently unproductive publication point to traverse. The resource holder, however, depends on the registry to detect failure accurately, reach the right contacts and preserve a usable restoration path.

That trade-off makes notification and evidence part of the rule’s substance. A threshold applied to a timestamp can be objective only if the timestamp records a verifiable condition. RIRs can reduce ambiguity by publishing the measurement method, separating discovery failures from CA publishing failures, retaining warning and response receipts, and distinguishing an expired object from an administratively revoked certificate.

The lesson is not that RIRs should use one number. It is that operators should be able to see the applicable number, the condition it measures and the point at which authority changes. RIPE’s first 35 revocations show that the rule is now operational. APNIC’s 60-day policy shows that comparison does not equal harmonization. For every affected CA, the controlling question remains local: what data stopped validating, when did the clock start, and what evidence could still stop revocation?

Sources consulted: NRO’s 2026-Q3 notice; Q3 comparative policy PDF; Q2 comparison; RIPE NCC implementation status; RIPE NCC’s 24 September operational update; RIPE-847; APNIC prop-166; APNIC 61 implementation update; Heng Lu, Note 70.