Summary

  • RIPE NCC Status reported that RIPE Access and API-key authentication for RIPE Atlas were not working at 11:27 CEST on 29 September. Nine minutes later it said a recent change had been rolled back and authentication appeared normal.
  • The incident remained in Monitoring until 09:47 CEST the next day, when RIPE NCC said logins had worked correctly since the prior update. The interval is not proof that users were locked out all night.
  • Atlas documentation says some private-data and measurement-control actions require authentication, while most public reads do not. The incident does not identify which endpoints failed or whether measurement execution was affected.

The login returned before the incident closed

At 11:27 CEST on 29 September, RIPE NCC’s status page reported a specific failure: authentication with RIPE Atlas using RIPE Access or API keys was not working. At 11:36, the page said a recent change had been rolled back and authentication appeared to be working normally again. At 09:47 the following morning, it marked the incident resolved and said authentication and logins had been working correctly since the last update.

That sequence matters more than a single red or green label. The first post is an observation time, not a proven start time for the fault. The second is a recovery report, not a root-cause analysis: the same update says RIPE NCC was still trying to identify the cause. The next morning’s resolution is a closure statement, not evidence that service remained unavailable until then.

There are therefore at least two clocks in the record. One runs from the first public report to the rollback update: nine minutes. The other runs from the rollback update to formal closure: 22 hours and 11 minutes. Neither tells us how long the underlying failure existed before it was reported. Nor does the second interval establish a continuous outage. The status page says authentication appeared normal after the rollback and later says it continued to work; it does not say that the service was broken throughout the night.

This distinction is easy to lose in incident summaries. A timeline may contain the date on which an engineer acknowledged recovery and a later date on which the incident was closed. Readers who collapse those events into one duration can overstate downtime. Readers who stop at “working normally again” can miss that the root cause was still unknown and that the incident had not yet passed whatever observation period RIPE NCC considered necessary.

Two ways to present a credential, not two proven failure domains

RIPE Atlas supports API keys for programmatic access and session-based authentication for browser applications. Its documentation describes API keys as the preferred programmatic method. A key is sent in an Authorization header and can be used without an active browser session. That is a real difference in how a client presents its authority.

It is not evidence that the two methods depend on separate infrastructure. The status page names both RIPE Access and API keys as failing, but says nothing about the identity provider, authorization service, database, deployment, network path or code that handled either method. It does not say whether the failure had one cause or two. It does not establish that an API key was designed or advertised as an emergency substitute for RIPE Access.

The practical conclusion is narrower. In this incident, a different credential form did not provide a documented fallback: the public report said both authentication methods were not working. That is a service-availability fact. It is not an architectural finding about shared backends. Credential diversity can reduce dependence on a person’s interactive login, but it cannot be treated as recovery independence unless the service has tested and documented the failure boundary.

Authentication protects a control surface

The boundary matters because Atlas authentication is more than a sign-in screen. The API manual lists functions that may require authorization: viewing non-public probe information and measurements, creating a measurement, stopping one, and managing probe participation. Those capabilities let a user inspect private state or change what the platform is doing. For an operator or researcher with a live task, inability to authenticate can be a control problem even if no probe has stopped measuring.

That last condition is important. The incident report does not say whether measurements already in progress continued, whether results were produced, or whether users could retrieve public results. RIPE Atlas documentation says most reads of public objects can be unauthenticated. That describes the API’s ordinary access model; it does not prove those requests were tested during this particular incident. The source therefore supports a distinction between an authentication event and a measurement-plane outage, not a claim that the public measurement service stayed fully available.

A credential gate can also affect actions differently. A public read, a private measurement lookup, creating a new measurement and stopping an existing one are not the same transaction. The status update reports a broad authentication symptom but does not name the endpoints or permission classes tested. Without that map, a user cannot tell whether “Atlas authentication is failing” means every credentialed request, only the browser flow, a particular API scope, or an intermittent subset.

What the public record can and cannot settle

The status page provides useful evidence: the affected service was named as RIPE Atlas; both authentication methods were called out; a recent change was rolled back; recovery appeared normal within nine minutes of the first update; and the incident was closed the next morning. It also preserved uncertainty by saying the cause was under investigation.

What it does not provide is equally important. There is no count of affected accounts, no request volume, no response-code sample, no affected-endpoint list, no start time before the first post, and no account of whether users retried or abandoned work. There is no statement about running measurements, probe connectivity, result delivery or public anonymous reads. The incident cannot support claims of lost data, stopped measurements, customer harm, malicious activity or a common authentication backend.

This is not a demand to publish credentials or private user records. A status report can disclose the operational boundary without exposing either. It can name tested authentication methods, identify which endpoint classes were unavailable, distinguish read-only public access from private or control actions, and say whether a recovery check was repeated after rollback. It can retain a separate field for root-cause analysis when the cause is not yet known.

The control is in the status transition

The operational mechanism is simple. A client presents a credential; the API verifies it; a permission check allows or rejects an action. If a recent change prevents credential validation, a valid key or session cannot reach the functions it authorizes. Reversing that change may restore access, but a rollback alone does not disclose which methods were verified or what remained unknown.

A clear status record would separate four claims: the fault was observed; a change was reversed; a defined set of authentication tests passed; and the incident was closed after a stated monitoring interval. RIPE NCC’s record contains the first, second and a general recovery statement, followed by closure the next morning. It does not identify the tests or the scope behind the word “normal.” That is a limit of public evidence, not proof that internal checks were absent.

Sources and scope. RIPE NCC’s incident record supplies the timeline and reported symptom. The RIPE Atlas authentication manual defines the two authentication methods and privileged actions; the API-key guide explains key use outside a browser session; and the anonymous-access guide describes public reads. These sources do not identify affected users, exact endpoints, measurement outcomes or the incident’s root cause. The RIPE NCC Status history corroborates the service classification and update sequence, but adds no endpoint-level or user-impact detail. RIPE NCC Status history.