Orange Spain made RIPE account security a routing-control accountability test

Summary

• The Orange Spain incident showed that a compromised RIPE NCC account can move from administrative access to routing impact when resource records and RPKI/ROA state are changed maliciously.
• Technical accounts from APNIC and Kentik describe how leaked or compromised credentials were used to alter RPKI-related routing state, causing legitimate Orange España prefixes to appear invalid and disrupting reachability.
• Accountability spans several control owners: Orange Spain controlled account security and monitoring; RIPE NCC controlled registry account controls and recovery processes; upstream and peer networks controlled validation/filtering behavior; customers bore connectivity harm.
• RPKI is not a magic shield. If the account authorized to publish ROAs is compromised, cryptographic route-origin validation can enforce the attacker's administrative change until detection and repair occur.
• A credible repair record should include multi-factor account protection, credential monitoring, least-privilege resource administration, route-change alerting, independent reachability monitoring, emergency registry recovery, and upstream filtering discipline.

Registry administration became an outage path

The Orange Spain incident was striking because the apparent path to disruption did not begin with a router CLI in the ordinary customer-facing network. Public technical accounts focused on compromise of Orange España's RIPE NCC account and malicious changes to routing-security information. APNIC's technical blog, Digging into the Orange España hack, and Kentik's parallel technical write-up describe how changes associated with the compromised account affected route-origin validation and caused reachability disruption. Those accounts are not Orange's internal root-cause report, but they are the strongest public technical record.

The key accountability point is that registry administration is part of network control. A RIPE NCC account is not just an administrative convenience. It can authorize changes to entities and route-origin data that the wider Internet may consume. When those changes affect RPKI validity, routers and operators that enforce validation can make traffic decisions based on them. Administrative access therefore becomes a route-control surface.

Cybersecurity news coverage captured the public impact. BleepingComputer reported that a hacker hijacked Orange Spain's RIPE account to cause BGP havoc. SecurityWeek reported that RIPE account hacking led to a major Internet outage at Orange Spain. The Record covered the Orange España outage and RIPE/BGP/RPKI context. These accounts agree on the broad shape: account compromise, route/RPKI manipulation, and customer reachability harm.

The incident should not be reduced to a lesson about one password. A weak or stolen credential may be the visible trigger, but the control question is larger. Why could an account with this authority be accessed? Was multi-factor authentication enforced? Were route-object and ROA changes monitored independently? Were emergency contacts and registry recovery processes fast enough? Did network monitoring distinguish internal faults from global validation effects? Did upstream and peer networks have enough validation discipline to reduce blast radius?

Customers had little control over any of this. A broadband subscriber or enterprise customer cannot inspect RIPE account security or route-object changes. They experience the result as degraded Internet reachability. That imbalance makes the event a public accountability issue for a national telecom operator.

RPKI can enforce good records or bad records

RPKI is often described as a route-security improvement because it lets holders of number resources authorize which autonomous systems may originate their prefixes. That is true. But the Orange Spain case shows the inverse: if the authority to create or change the authorization is compromised, the validation ecosystem may enforce an attacker-controlled state. RPKI makes route-origin information more machine-enforceable; it does not make account compromise impossible.

RIPE's RPKI documentation explains the basic role of ROAs and route-origin validation in the RIPE context. RFC 6811, BGP Prefix Origin Validation, defines how routers can classify routes using RPKI origin data. RFC 8210, The RPKI to Router Protocol, describes the protocol by which validated cache information reaches routers. These documents explain why the incident mattered: changes in authorized origin data can influence route acceptance across networks that validate.

Ben Cox's technical essay, RPKI: signed but not secure, is useful because it warns against treating signature as sufficient security. A signed authorization can still be wrong if the signing authority or account is compromised. Cryptographic integrity proves that a record came through an authorized path; it does not prove that the authorized path was safely governed.

That distinction is central to accountability. Orange Spain needed to secure the accounts and processes that could affect route-origin state. RIPE NCC needed strong account controls and rapid recovery paths. Other operators needed route validation and monitoring that made anomalous changes visible. Customers needed reachability, but they had no practical way to inspect the trust chain.

RPKI remains valuable. The lesson is not to abandon it. The lesson is to govern it as a critical control plane. A ROA change should be treated more like a production network change than like a routine administrative update. It can affect reachability, customer service, interconnection, and public trust.

Credential theft was a trigger, not the whole failure

Several reports linked the incident to stolen or weak credentials. The Hacker News reported that Orange Spain faced BGP traffic hijack after RIPE credentials were compromised. The Register reported that a weak password and infostealer were blamed for the outage. DoublePulsar's early analysis, How 50% of telco Orange Spain's traffic got hijacked, connected leaked credentials, RIPE access, and traffic impact.

These sources should be used carefully because public reporting cannot replace Orange's internal security evidence. The general control lesson is clear, however: Internet-resource accounts need the same or stronger protection as privileged infrastructure accounts. If a RIPE NCC account can alter RPKI or route objects, it should not be protected by a weak password, reused credential, or optional second factor. It should have strong authentication, role separation, monitored access, emergency revocation, and credential-leak detection.

Resecurity's report, Hundreds of network operators' credentials found circulating in dark web, places the incident in a broader credential-risk context. Whether or not a specific credential source was used in this incident, the broader point is that network-operator credentials are high-value targets. Infostealer ecosystems can turn ordinary workstation compromise into infrastructure-control risk.

Credential security also includes endpoint hygiene. If an administrator's browser, password vault, or workstation is compromised, a strong registry password may be exposed. Multi-factor authentication helps, but phishing-resistant MFA, device posture, access logging, and session management can matter. A registry account should not be accessible from unmanaged or poorly protected endpoints.

Account privilege should also be scoped. A person who needs to update billing or contact data may not need to change ROAs. A person who can manage ROAs may not need broad organizational account control. Emergency access may be needed, but it should be logged and reviewed. Least privilege is familiar in enterprise systems; the Orange incident shows why it applies to Internet number-resource administration.

Monitoring should catch route-origin state, not only routers

Network operators monitor routers, links, interfaces, utilization, latency, and customer tickets. The Orange Spain incident shows that monitoring must also include external routing state and route-origin validity. If attackers change registry or RPKI state, the operator may see traffic shifts, invalid routes, customer reachability failures, and global measurement anomalies before it sees an internal router fault.

APNIC and Kentik's technical accounts used global routing observation to explain what happened. That is a hint for operators: independent route monitoring is not optional. A telecom operator should watch whether its prefixes are visible, whether they are valid under RPKI, whether expected origins change, whether route collectors show anomalies, and whether major peers or transit providers are rejecting routes. This monitoring should alert the team that owns registry and RPKI changes, not only the team that owns routers.

RIPE's database documentation explains the registry/database context. RIPE's Access documentation explains the account surface. These administrative systems should be tied to operator monitoring. If a route object, ROA, maintainer, contact, or authorization changes, the operator should know quickly and independently.

Independent monitoring is important because a compromised account can make malicious changes through the legitimate interface. Logs inside the account system may show a successful login and authorized action. The operator needs a second view: does this change match a planned maintenance ticket? Does it invalidate active prefixes? Does it conflict with observed BGP announcements? Does it affect customers? Does it require emergency rollback?

The monitoring standard should include simulation. Operators can test what happens if a ROA is accidentally changed, if a route becomes invalid, if a peer rejects a prefix, or if a credential is revoked. Exercises make the response faster when the event is real.

Upstream and peer filtering shape the blast radius

Routing incidents spread through the behavior of many networks. A malicious or erroneous route-origin state matters most when other networks act on it. That does not make validation bad; it makes validation policy and coordination important. Operators need to know how peers and transit providers treat invalid routes, how quickly changes propagate, and how emergency repair is communicated.

MANRS' network operator actions define practical routing-security commitments such as filtering, anti-spoofing, coordination, and global validation. Applied to Orange Spain, the MANRS lens asks whether networks had appropriate route filtering and whether coordination channels could reduce the duration and scope of harm. Routing security is an ecosystem duty, not a one-operator checkbox.

Academic work such as deployment studies of RPKI validation and later systematization of RPKI vulnerabilities and deployment risks reinforces the same point: validation behavior varies, implementation details matter, and routing-security mechanisms can introduce new operational dependencies. These studies are not incident reports, but they help explain why a compromised ROA or registry account can have uneven effects across the Internet.

For Orange Spain, the practical question is whether upstreams, peers, and major networks received clear and fast remediation signals. Was there an emergency route-security contact path? Were invalid routes revalidated quickly after repair? Did customers see partial restoration depending on which paths their traffic used? Did monitoring identify which networks were still rejecting traffic? The public record does not answer all of these questions, but the questions define the accountability surface.

For other telecom operators, the lesson is to maintain an out-of-band routing incident plan. If an operator's prefixes become invalid because of registry compromise or mistake, who can contact RIPE NCC? Who can contact major transit providers? Who can publish an authenticated incident notice? Who can temporarily adjust route-origin state? Who validates restoration? A plan written after the incident is useful; a practiced plan is better.

RIPE NCC's role is procedural and systemic

RIPE NCC was not the alleged attacker and did not operate Orange Spain's customer network. Its role is different: it provides registry services, account infrastructure, database services, RPKI services, and recovery processes for its service region. When a member account is compromised, RIPE NCC's controls and procedures affect how quickly malicious changes can be detected, frozen, reversed, and learned from.

The public should be careful not to assume that any account compromise proves negligence by a registry. Members control their credentials and devices. But registries can shape risk through mandatory MFA, privileged-action confirmation, anomaly detection, contact verification, emergency lockout, role separation, and change notifications. High-impact RPKI changes may deserve stronger confirmation than low-risk profile edits.

The incident therefore raises a systemic question: should Internet resource registries treat certain actions as safety-critical? Creating, deleting, or changing ROAs for active large networks can affect reachability. So can changing maintainers or route objects. A registry can preserve member autonomy while adding friction and alerts for high-impact actions.

The registry can also help the community learn. Without exposing sensitive member details, it can publish guidance on account protection, incident reporting, RPKI change monitoring, and emergency recovery. It can encourage or require stronger authentication for accounts with routing authority. It can improve logs and notifications. It can coordinate with MANRS and operator groups.

The Orange Spain incident should be read as a warning for every regional Internet registry and resource holder. The security of Internet number-resource administration is part of operational Internet stability.

Customer notice should explain reachability, not just cybersecurity

When customers lose reachability because of routing disruption, a cybersecurity statement may not answer the practical question. Customers want to know whether broadband, mobile, enterprise connectivity, DNS, cloud services, and external reachability are affected. They want expected restoration and whether they need to change anything. They do not need every BGP detail, but they deserve more than a vague statement about a technical issue.

Orange Spain's public communication was reported through social and press channels, but the richer technical explanation came from third-party routing observers. That is common in routing incidents: external researchers can sometimes explain the visible BGP state faster than the affected operator publishes a detailed account. A mature operator should be able to bridge that gap. It can explain in customer language that routing records were altered, that some networks rejected legitimate routes, that repair is underway, and that customers do not need to change equipment.

Customer notice also matters for enterprise customers. Businesses may see partial reachability, cloud problems, VPN failures, or customer-access issues. They need to know whether the problem is their own network, a provider outage, or a global routing-state issue. Clear notice reduces wasted troubleshooting and support calls.

Regulators may need a different level of notice. A national telecom operator outage can affect emergency services, public agencies, businesses, and consumers. Even if the incident is short, the route-control mechanism may be serious. A regulator does not need every credential detail in public, but it may need assurance that privileged account security and routing-change monitoring were repaired.

The accountability record should include how quickly Orange Spain identified the route-control problem, how it notified affected groups, and what it changed afterward. Without that record, public learning depends too heavily on external researchers.

Residual unknowns and the accountable question

The public record does not include Orange Spain's full internal root-cause analysis, account-security configuration before the incident, exact credential source, complete incident timeline, customer-impact count, regulator communications, or post-incident remediation evidence. It does not show RIPE NCC's internal response details or every upstream provider's filtering behavior. Those gaps should not be filled with speculation.

What is known is enough to define accountability. A compromised or abused RIPE account associated with Orange Spain was used to alter routing-security state. Technical observers saw RPKI/ROA-related changes that made legitimate routes invalid and disrupted reachability. Public reporting linked the event to credential compromise and a multi-hour outage. Customers experienced connectivity harm without control over the registry account or route-origin data.

The accountable question is whether Orange Spain and the routing ecosystem can prove that administrative access cannot again become customer reachability harm so easily. For Orange Spain, that means strong account authentication, credential hygiene, least privilege, route-change monitoring, independent RPKI validity alerts, emergency rollback, and customer notice. For RIPE NCC, it means account-control design, high-impact change alerts, emergency support, and member guidance. For peers and upstreams, it means validation discipline and coordination.

RPKI remains a necessary routing-security tool. The incident should not be misused as an argument against validation. It should be used as an argument for governing the whole trust chain: credentials, accounts, ROAs, validators, routers, monitoring, and communication. A cryptographic system is only as accountable as the operational processes around it.

For customers, the lesson is sober: Internet reachability depends on administrative systems most users never see. That is why telecom operators owe public evidence after routing-control failures. The Internet is resilient because many networks coordinate. It becomes fragile when one privileged account can silently undermine the route record until the world notices.

Route-change governance should look like production change governance

The first practical repair is to treat route-origin and registry changes like production network changes. A ROA edit, route-object change, maintainer change, or registry-account role change can affect reachability. It should have a ticket, a peer review, an expected effect, a rollback path, a notification trail, and monitoring. If the organization would require review before changing a core router policy, it should require review before changing the signed data that other routers may use to accept or reject its prefixes.

This does not mean every small administrative update needs a heavy committee. It means high-impact actions need stronger process. Deleting a ROA for an active prefix, changing the origin AS for a production prefix, altering a maintainer, or adding a new user with resource authority should trigger alerts and perhaps out-of-band confirmation. Automated guardrails can distinguish routine low-impact updates from changes that would invalidate active routes.

The guardrails should include "known good" comparisons. If Orange Spain normally originates a set of prefixes from expected ASNs, a sudden change that invalidates a large share of active announcements should be treated as dangerous until proven planned. The organization should not wait for customer reports. It should know from its own monitoring that the routing-control plane has changed in a way inconsistent with current operations.

This governance also needs emergency speed. If a route-origin mistake or malicious change is active, the operator cannot wait for ordinary ticket review. It needs an emergency reversal path with clear authorization and post-action audit. Speed and control are not opposites. A mature emergency process is fast because it was designed before the incident.

The Orange incident is a reminder that administrative systems deserve change windows, but also anomaly windows. A scheduled planned change can be validated before and after. An unscheduled change to a critical route object should create an immediate incident. The system should make the difference visible.

Credential monitoring should extend into infostealer ecosystems

Public reporting connected the incident to stolen or weak credentials, and the wider security ecosystem has shown how infostealer logs can circulate credentials for infrastructure services. That creates a hard lesson for network operators: password policy is not enough. Credentials can be stolen after they are created, outside the registry's direct control, through infected endpoints, browser stores, reused passwords, or compromised personal devices.

Operators should monitor for exposed credentials tied to corporate domains, registry accounts, cloud services, Git repositories, VPNs, and privileged portals. This does not mean trusting every dark-web vendor claim. It means having a process to receive, verify, and revoke possible exposures quickly. A leaked registry credential is not an ordinary low-priority ticket. It can alter the public route record.

Multi-factor authentication should be phishing-resistant where possible for high-impact accounts. If an attacker can capture both password and session token, ordinary MFA may not be enough. Privileged registry access can be limited to managed devices, secure browsers, hardware keys, or dedicated administrative workstations. These controls may feel heavy, but they are proportionate when the account can affect national customer reachability.

The registry and the operator can both contribute. The operator can secure endpoints and monitor credentials. The registry can enforce MFA, show active sessions, alert on unusual login geography or device changes, and require stronger confirmation for high-impact RPKI changes. Neither side alone owns the whole risk. That is why the accountability record should name both roles.

Credential rotation after an incident should also be broad enough. If one account was compromised by an infostealer, other accounts used from the same endpoint or stored in the same environment may also be at risk. A narrow reset can leave adjacent control paths exposed. The repair question is not "was the RIPE password changed?" but "was the administrative access environment made safer?"

A routing incident response drill has different entities

Telecom incident response often includes network operations, security operations, customer care, enterprise support, regulatory affairs, executive communications, and vendor management. A routing-control incident adds registry contacts, RPKI specialists, peering coordinators, transit providers, Internet exchange contacts, route-monitoring vendors, and possibly regional Internet registry emergency contacts. If those people are not in the drill, the drill is incomplete.

The drill should start with symptoms: customers report partial reachability, route collectors show invalid prefixes, major peers stop accepting routes, external monitoring shows traffic drop, and internal routers look healthy. The team should practice recognizing that this is not a fiber cut, DNS problem, or ordinary DDoS. It is a route-origin validation problem or registry-control problem.

The drill should then test authority. Who can access the RIPE account? Who can revoke compromised users? Who can restore ROAs? Who can authenticate to RIPE NCC under emergency conditions if normal accounts are compromised? Who can contact major transits and peers? Who approves customer statements? Who informs regulators? The answers should not depend on one engineer being awake.

The drill should include a "bad recovery" scenario. A rushed ROA change might restore one prefix while invalidating another. A public statement might say the issue is resolved while some networks still reject routes. A credential reset might lock out legitimate administrators. A peer might cache stale validation data. Practicing these failure modes reduces the chance of declaring recovery too early.

Finally, the drill should create artifacts: contact lists, emergency scripts, validation dashboards, message templates, rollback steps, and post-incident review questions. Artifacts are what remain when people move roles. Routing security is too important to live only in institutional memory.

Customer-impact measurement should use external vantage points

Customer impact in routing incidents can be uneven. Some customers may reach certain services while others cannot. Some destinations may be reachable through networks that do not reject invalids. Others may fail because major networks enforce validation. Internal service metrics may understate the problem if they do not reflect external path diversity. That is why external vantage points matter.

An operator should measure reachability from multiple networks, regions, and service types. Can customers reach major cloud providers? Can external users reach customer-hosted services? Are DNS resolvers reachable? Are CDN paths affected? Are mobile and fixed customers affected differently? Does traffic recover when ROAs are corrected, or do some networks require additional refresh or coordination?

Kentik and APNIC's public analysis demonstrates the value of global measurement. External observers could connect route-origin state to traffic impact. An operator should have its own equivalent monitoring or trusted partner feed. Depending solely on customer complaints is too slow. Depending solely on internal router health is too narrow.

Customer-impact measurement should also inform communication. If impact is partial, say so carefully. If some external networks continue to reject routes after repair, customers should know that restoration may be uneven. If enterprise customers need to inform their users, they need language that explains the provider-side nature of the issue. A routing incident is confusing for customers because their local equipment may appear healthy.

After the incident, the operator should compare observed impact with monitoring coverage. Did alerts fire before customers complained? Did dashboards identify invalid route state? Did support teams receive accurate incident classification? Did traffic metrics correlate with BGP validation status? The answers become monitoring improvements.

Regulatory learning should focus on control evidence

National telecom operators are critical public infrastructure in practice, even when the immediate failure mechanism is a registry account. Regulators and public authorities should learn from this event without turning every BGP detail into a public compliance checklist. The useful regulatory question is evidence: can the operator prove that privileged route-control accounts are protected, monitored, and recoverable?

Evidence might include MFA enforcement for registry accounts, privileged-access reviews, route-origin change logs, external validation monitoring, emergency contact procedures, incident drills, customer-notice thresholds, and post-incident lessons learned. A regulator does not need passwords or secret diagrams. It needs assurance that the operator understands the route-control surface and has strengthened it.

Regulatory attention should also avoid punishing transparency. If an operator discloses a routing-control incident and publishes useful repair categories, that should be treated as part of accountable response. The worse outcome is a culture where operators hide routing incidents because the mechanism sounds embarrassing or specialized. Public reachability failures deserve explanation.

At the same time, "technical complexity" should not become a shield. BGP, RIPE accounts, ROAs, and RPKI may be specialized, but the public consequence is simple: customers could not reliably reach the Internet. A national operator should be able to translate specialist failure into public accountability language.

Regulators can also encourage sector-wide exercises. Telecom operators, registries, major transit providers, and Internet exchanges can practice compromised-resource-account scenarios. The Internet's operational culture is built on coordination; formalizing a few high-impact drills would improve readiness without waiting for the next public outage.

The economics of route security can create underinvestment

Route-security controls often suffer from a mismatch between who pays and who benefits. An operator pays for account hardening, monitoring, drills, and staff time. The wider Internet benefits when routes are stable and secure. Customers benefit when outages do not occur. Because successful prevention is invisible, underinvestment can persist until a failure becomes public.

The Orange Spain incident makes the business case more visible. A few hours of reachability disruption for a major telecom can create customer churn risk, regulatory attention, support costs, reputational damage, engineering distraction, and public embarrassment. The cost of stronger account security and route monitoring is modest compared with the public cost of a route-control compromise.

There is also a reputational dimension for RPKI itself. If public stories frame RPKI as the cause of an outage, organizations may hesitate to deploy validation. That would be the wrong lesson. The better lesson is that RPKI makes route-origin security more enforceable, and therefore account governance around RPKI must be stronger. A mature ecosystem can hold both ideas at once.

Network operators should budget route security as operational resilience. That includes staff who understand RPKI, tooling that monitors validity, contracts or services for external route visibility, and time for exercises. It also includes training customer-support teams enough to recognize when a routing incident is not a modem problem.

The economics improve when the ecosystem shares tooling and norms. MANRS, regional network operator groups, registries, and observability providers can make best practices easier to adopt. The Orange incident should encourage that shared investment.

Evidence of repair should be durable

After a public routing incident, it is common to fix the immediate issue and move on. Durable repair requires more. The operator should produce an internal evidence file that can be reviewed months later: what changed, who owns it, how it is tested, and what metrics prove it still works. Without durable evidence, the incident becomes folklore.

The evidence file should include account hardening, access review results, MFA enforcement status, emergency contact tests, RPKI monitoring screenshots or reports, drill outcomes, customer-communication updates, and peer-coordination lessons. It should also include unresolved risks. Not every control can be perfect immediately, but unresolved risk should have an owner and target date.

Some evidence can be shared publicly or with regulators. The public does not need to see every dashboard. It can be told that privileged registry access now requires stronger authentication, that route-origin changes trigger independent alerts, that emergency RIPE recovery paths were tested, and that customer communication procedures were updated. Those categories build trust without disclosing sensitive detail.

Durability also means onboarding. New network engineers, security staff, and customer-operations teams should learn from the incident. If only the response team remembers it, the organization will repeat mistakes when staff rotate. A routing incident should become a training case, not a forgotten anomaly.

The public record from APNIC, Kentik, and the press already educates the wider community. Orange Spain's own durable repair evidence would complete the accountability loop.

The simplest control is also the easiest to miss

The simplest control is an alert that asks, "Did we mean to do this?" If a ROA change invalidates active production prefixes, if a registry account logs in from an unusual environment, if a new privileged user is added, or if route-origin state diverges from the live network plan, someone should be asked that question immediately. The alert does not need to know whether an attacker is present. It only needs to know that the change is dangerous enough to verify.

That kind of alert is effective because many routing incidents are not subtle once the right comparison exists. The intended origin, the active origin, the current ROA, the previous ROA, and the observed route state can be compared automatically. If the comparison fails, the organization can escalate before customers become the monitoring system. The Orange Spain case shows how valuable that escalation can be.

Operators should also store the answer. If the change was intended, the ticket and approver should be visible. If it was unintended, the incident record should show how long detection, reversal, and external propagation took. Over time, those records become a route-control quality metric. They show whether the organization is learning or merely reacting.

The metric should be reviewed with the same seriousness as packet loss or core availability. A telecom operator that can prove low time-to-detect for unsafe route-origin changes has a stronger resilience story than one that only proves router uptime. The customer does not care which control plane failed; the customer cares whether the Internet worked. Route-control metrics connect the invisible administrative layer to the visible service promise.

That is the useful lesson of the incident: protect the account, validate the route, watch the outside world, and rehearse the reversal before the next credential turns administrative trust into public outage.

Those basics are small, but the public consequence is not.

Additional evidence boundary

For Orange Spain made RIPE account security a routing-control accountability test, the additional evidence boundary is to keep confirmed facts, evidence-backed inference, and unknown information separate. That separation matters because an event involving orange spain ripe account route hijack filtering can be described as a technical problem, a contract problem, or a communications problem depending on which actor is speaking.

The accountability analysis therefore has to return to practical control: who could change the configuration, limit exposure, accelerate detection, authorize notification, or prove that repair had reached the affected users.

This lens adds a careful test of root cause and triggering event. The trigger explains why the event became visible at a particular moment; the root cause requires evidence about design, control, governance, and verification choices that existed before that moment. Contributing conditions such as dependency, delegation, change windows, contracts, logs, and incentives should be evaluated without treating a company statement as the complete truth or turning a possibility into a settled conclusion.

The same discipline applies to detection failure, response failure, and recovery failure. The public record should show when the signal was seen, who had authority to act, what customers or regulators were told, and which additional evidence would make the conclusion stronger or weaker. While those elements remain partial, the responsible conclusion is not an extra accusation; it is a more precise map of responsibility, uncertainty, and the control-plane and dependency controls that a later audit should verify.