Cisco IOS XE exposed the accountability problem of management planes left on the internet

Summary

• Confirmed public record: Cisco disclosed active exploitation of the IOS XE Software web UI feature and later determined that attackers exploited two previously unknown issues: CVE-2023-20198 for initial access and privilege 15 account creation, followed by CVE-2023-20273 to elevate to root and write an implant to the file system. (Cisco security advisory)
• Government guidance: CISA said the two vulnerabilities affected IOS XE Web UI and could allow an unauthenticated remote actor to take control of an affected system; CISA urged organizations to disable the HTTP Server feature on internet-facing systems, hunt for malicious activity and upgrade to fixed software releases when available. (CISA guidance)
• Management-plane issue: The public record supports a control-surface failure involving exposed web management, account creation, command injection and implanting. It does not support a blanket claim that every IOS XE device was affected, that every exposed device was compromised, or that Cisco alone controlled each customer's internet exposure.
• Assessment: Attackers controlled the exploitation. Cisco controlled product code, advisory content, fix delivery, hardening guidance and detection support. Customers, MSPs and public agencies controlled exposure, inventory, configuration, segmentation, monitoring and recovery discipline. The event turned "is the web UI enabled on the internet?" into a board-level continuity question.

The network device was the control point, not just another server

The Cisco IOS XE web UI incident matters because a router, switch or wireless controller is not just a workload. It is a control point for other workloads. A compromised network device may sit in the path of authentication, traffic routing, segmentation, branch connectivity, wireless access, voice, monitoring and incident response itself. When management-plane compromise reaches such a device, the recovery question is not only whether a CVE has been patched. It is whether the device can still be trusted to describe, enforce and protect the network around it.

Cisco's advisory placed the event in the web UI feature of IOS XE Software and made clear that the attack chain involved active exploitation. The attacker first used CVE-2023-20198 to gain initial access and issue a privilege 15 command to create a local user and password combination. The attacker then exploited another component of the web UI feature, CVE-2023-20273, using the newly created local user to elevate privilege to root and write the implant to the file system. Cisco assigned CVSS 10.0 to CVE-2023-20198 and 7.2 to CVE-2023-20273. (Cisco security advisory)

CISA's public guidance translated the same facts into operator urgency. CISA described active, widespread exploitation of CVE-2023-20198 and CVE-2023-20273 affecting Cisco IOS XE Software Web UI, said an unauthenticated remote actor could exploit the vulnerabilities to take control of an affected system, and told organizations running IOS XE Web UI to implement Cisco's mitigations, including disabling the HTTP Server feature on internet-facing systems, and to hunt for malicious activity. (CISA guidance)

The management-plane aspect is the difference between a vulnerability story and an accountability story. An application flaw in an ordinary web server can be serious; a flaw in a management interface for devices that steer packets and enforce policy is a control-plane risk. The attacker does not merely steal data from a single application. The attacker may gain a position from which to observe, alter, persist or prepare further access against the network's trusted machinery.

That does not mean every affected device was used for traffic interception or destructive action. The public primary record does not support such a universal claim. Cisco and CISA documented account creation, root escalation and implant writing as the exploitation pattern. The accountable question is what that access could mean and what evidence is required before an operator can treat the device as trustworthy again.

For many organizations, especially SMEs and public agencies with lean network teams, management interfaces are historically practical conveniences. Web UI administration may make remote configuration easier. MSPs may use it for customer support. Branch teams may leave it reachable after deployment. A control that begins as a convenience can become an internet-facing attack surface if exposure is not continuously inventoried and constrained.

Cisco disclosed the chain while the fix story was still moving

The public chronology is important because exploitation, mitigation and fixed releases did not arrive as one tidy package. Cisco initially warned of active exploitation and recommended defensive steps, including disabling the HTTP Server feature on internet-facing systems. Later advisory updates added the second CVE, fixed release information and a software checker. CISA's page was updated with fixed release availability for several IOS XE trains and linked operators back to Cisco's advisory and fix documentation. (Cisco advisory, CISA guidance)

That sequence created a practical accountability window. When exploitation is active and the full fix matrix is still being assembled, the mitigation burden shifts sharply to exposure reduction and detection. Operators cannot wait for a perfect patch plan if the management interface is reachable. They must disable or restrict the HTTP/HTTPS server feature on internet-facing systems, hunt for newly created or unexplained users, review indicators, preserve evidence and decide whether a device is potentially compromised.

Cisco's Software Fix Availability document later gave operators a more concrete way to map bug ID CSCwh87343 to IOS XE fixed releases. CISA's November 1 update listed fixed releases for release trains including 17.9, 17.6, 17.3 and 16.12 for certain Catalyst 3650 and 3850 devices. The distinction matters: during the early exploitation window, the most important control could be "close the management-plane exposure now." After fixed releases exist, the control becomes "upgrade, verify, hunt and recover." (Cisco fix availability, Cisco Software Checker)

The National Vulnerability Database entries and CVE records provide additional public anchors for the vulnerabilities. NVD's CVE-2023-20198 page points to the Cisco advisory and describes the active exploitation context. CVE.org records preserve the vulnerability identifiers as part of the public vulnerability record. (NVD CVE-2023-20198, NVD CVE-2023-20273, CVE record CVE-2023-20198, CVE record CVE-2023-20273)

The chain also shows why CVSS alone is insufficient for governance. A 10.0 score on CVE-2023-20198 signals technical severity, but the business risk varies by exposure, role and recovery capability. An internet-exposed branch router with weak logging and no known clean image creates a different operational problem than an internal lab device behind management VPN controls. Severity tells leadership to pay attention. Inventory and exposure evidence tell leadership what to do first.

Internet exposure was the consequence multiplier

The most important operator-controlled variable was whether the web UI management surface was reachable from the internet. Cisco and CISA's mitigation language centered on disabling the HTTP Server feature on internet-facing systems. Cisco's hardening guidance is consistent with that control: Cisco's IOS and IOS XE hardening materials state that the HTTP server can be disabled with no ip http server and the secure HTTP server can be disabled with no ip http secure-server. (Cisco IOS XE Software Hardening Guide, Cisco Guide to Harden Cisco IOS Devices)

This is not a new security principle. Management interfaces should not be broadly internet exposed unless there is a strong, monitored, restricted and documented reason. CISA's Binding Operational Directive 23-02 on internet-exposed management interfaces directed federal civilian agencies to reduce risk from exposed management interfaces, and its recommendations have broader relevance outside the federal boundary. (CISA BOD 23-02)

The problem is that real networks accrete exceptions. A device deployed during a merger keeps old access rules. An MSP opens a management path for urgent troubleshooting and never closes it. A branch office inherits a template with HTTP enabled. A public IP changes ownership. A firewall rule meant for a temporary migration becomes permanent. The web UI is not necessarily exposed because one engineer made a reckless decision. It can be exposed because asset inventory, change control and managed-service handoff failed to keep up with the network's history.

That history matters for blame. Cisco controlled whether the product vulnerability existed and how quickly it was diagnosed and fixed. Customers controlled whether the vulnerable management surface was reachable. MSPs controlled many customer configurations. Public agencies controlled their own inventories and emergency disablement processes. Attackers exploited the reachable systems. Accountability follows those control points rather than collapsing into a single sentence.

For SMEs, the exposure problem is especially hard. A small organization may rely on a managed-service provider for network-device configuration and may not know whether IOS XE Web UI is enabled, exposed, internally restricted or unused. It may not know which release train it runs, whether fixed software is available, or whether an unexplained local user has appeared. When CISA says to disable the HTTP Server feature on internet-facing systems and hunt for malicious activity, an SME may need its provider to translate that into specific device checks and evidence.

This is why the incident is not only about Cisco and large enterprises. It is a test of the managed-network support economy. If MSPs can centralize customer network administration, they must also centralize accurate exposure inventory, rapid mitigation and proof of recovery. The customer cannot accept "we patched it" as enough if the device may have had a root-level implant before patching.

The implant changed patching into recovery

The public facts include implant writing, and that changes the work. When a vulnerability only allows unauthenticated account creation, removing the account and patching may be enough in some cases. When the chain includes root escalation and an implant written to the file system, operators must treat affected devices as potentially compromised systems requiring forensic triage and recovery validation.

CISA's guidance points organizations to hunting for malicious activity and references Cisco Talos detection methods. The Cisco Talos blog is a key public detection source even where automated access to the page is restricted; CISA quoted it for the practical advice that organizations should look for unexplained or newly created users on devices as evidence of potentially malicious activity. (Cisco Talos blog, CISA guidance)

The phrase "newly created user" can sound mundane. On a network device, it is not. A local user with privilege created through exploitation may survive casual review, be reused for later access or provide evidence of tampering. Root-level command execution raises deeper questions about configuration integrity, file-system state, boot images, persistence, logs and whether the device's own telemetry can be trusted.

Patching closes the known vulnerability path. It does not automatically prove that a compromised device has no remaining implant, unauthorized account, altered configuration or hidden persistence. Recovery evidence therefore needs several layers: identify whether the web UI was enabled; determine whether it was internet reachable; check for suspicious users and indicators; collect and preserve logs where available; remove unauthorized accounts; upgrade to fixed software; compare running and startup configurations; verify image integrity; rebuild or reimage where compromise is suspected; and monitor after return to service.

NIST's incident handling guidance is useful here because it treats recovery as a phase, not a checkbox. Detection, containment, eradication and recovery are related but not identical. A device can be patched while evidence is still being collected. A device can be returned to service while monitoring is still elevated. A device can be "fixed" from a vulnerability-management point of view but still unresolved from an incident-response point of view. (NIST SP 800-61 Rev. 2)

This distinction should shape board reporting. A report that says "all devices patched" may be technically true and still incomplete. Leadership needs to know how many devices had the vulnerable feature enabled, how many were internet exposed, how many showed indicators of compromise, how many were rebuilt, how many had unauthorized users, whether any logs were unavailable, and whether managed-service customers received evidence. Those are recovery metrics, not only patch metrics.

Detection evidence was uneven by design

Network devices are often treated as sources of truth. They produce logs, enforce ACLs, route traffic and report status. In a management-plane compromise, that assumption weakens. If an attacker can create users and execute commands with elevated privileges, the device's own records may be incomplete, altered or absent. The operator may need external evidence: NetFlow, firewall logs, SIEM records, configuration backups, out-of-band management logs, TACACS or RADIUS logs, EDR-like network telemetry and comparison against known-good configurations.

This is the "network-resource evidence" issue in the manifest. The compromised resource is not only evidence-bearing; it is evidence-shaping. If the router or switch is the place where logs should have been generated, and that device is compromised, the quality of evidence depends on whether logs were exported and protected before the incident. A local log buffer on the device may be useful but fragile. Centralized logging and AAA records become much more important.

CISA's Known Exploited Vulnerabilities catalog is also evidence infrastructure. Listing CVE-2023-20198 and related exploited vulnerabilities gives agencies and operators a prioritization signal that the issue is not theoretical. The KEV catalog and Binding Operational Directive 22-01 created a federal process for remediating known exploited vulnerabilities, and many private organizations use the catalog as a triage signal. (CISA Known Exploited Vulnerabilities Catalog, CISA BOD 22-01)

Still, KEV inclusion does not tell an operator whether its device was compromised. It tells the operator that exploitation is known and that remediation should be prioritized. The operator must still answer the local evidence questions: Was the feature on? Was it reachable? Was it probed? Was a user created? Was the implant present? Was fixed software installed? Was the device rebuilt? Were downstream routes, ACLs or credentials changed?

Credential evidence is especially important. If an attacker created a local account, the device may also have had access to AAA servers, SNMP communities, network management systems, automation credentials, backup repositories or configuration archives. The public Cisco and CISA advisories do not say that all such downstream systems were accessed. They do create a rational reason to verify whether device-local compromise could have exposed broader management credentials or trust relationships.

For organizations using centralized authentication, a local account should be anomalous. For organizations with a mix of local emergency accounts and external AAA, the investigation is harder. A suspicious account may hide among legitimate break-glass accounts if naming, documentation and periodic review are weak. The incident therefore rewards boring governance: unique accounts, AAA logging, configuration baselines, frequent backups, least privilege and a clean inventory.

Cisco's role was broader than writing a patch

Cisco's accountability includes the product vulnerability, but it does not end there. A vendor of network operating software controls secure design, code review, default posture, advisory clarity, fix delivery, software compatibility, detection guidance, TAC capacity, hardening documentation and the ability of customers to identify affected releases. In this incident, Cisco disclosed the chain, identified two CVEs, provided recommendations, published fixed release information and maintained hardening guidance.

The fix matrix matters because IOS XE is not a single version on a single appliance. Large networks may include different release trains, hardware families, support contracts, operational constraints and maintenance windows. A "patch now" instruction is directionally correct but operationally incomplete. Customers need to know which images are fixed, which SMUs exist, which trains are still supported, which devices need upgrades, and whether an upgrade risks downtime. Cisco's fix availability document and software checker help with that translation. (Cisco fix availability, Cisco Software Checker)

Advisory clarity matters as much as fix availability. During active exploitation, the advisory has to tell operators what to disable, what to look for, what is affected, what is not affected, whether workarounds exist, when fixed software is available, and how to interpret indicators. Cisco's advisory did more than assign CVEs; it explained the observed chain from initial access to local user creation to root elevation and implant writing. That is the sort of information that changes response from routine patching to compromise assessment.

Vendor defaults are a fair but careful question. It is not enough to ask whether the web UI exists. Management features often exist for legitimate reasons. The better question is whether the product and documentation make unsafe exposure difficult, visible or noisy. If an HTTP/HTTPS management server is enabled, can operators easily see whether it is reachable from untrusted networks? Are templates and wizards biased toward least exposure? Do warnings make clear that internet-facing management is dangerous? Does telemetry show internet exposure? Does the software help operators disable unused management services?

Cisco's hardening documents advise reducing management-plane exposure. That is useful. But hardening documents compete with deployment pressure, inherited configurations and the operational habit of "it worked last time." Secure-by-design expectations increasingly ask vendors to make the safe path easier than the exposed path. CISA's secure-by-design guidance argues that technology manufacturers should take more ownership of customer security outcomes, not merely publish hardening checklists. (CISA Secure by Design)

Applying that principle here does not make Cisco solely responsible for every exposed device. It does ask whether network products can do more to surface management exposure, discourage internet reachability, reduce reliance on post-deployment hardening and help operators prove current state. A warning in a guide is not the same as a control in a product.

Customer and MSP accountability cannot be outsourced to Cisco

Customers controlled many of the variables that determined blast radius. They decided or inherited whether the web UI was enabled, whether HTTP/HTTPS management was reachable from the internet, whether management access was restricted to VPN or dedicated networks, whether configurations were backed up, whether logs were centralized, whether local user accounts were reviewed, and whether vulnerable devices were discoverable quickly.

Managed-service providers controlled those variables for many customers. That makes the MSP role central. If an MSP administers customer network devices, it should maintain an accurate device inventory, release inventory, management-exposure inventory, AAA model, backup state, logging state and emergency mitigation playbook. When a Cisco advisory lands, the provider should not begin by asking which customers might have the feature exposed. It should already know.

The SME continuity impact flows from that dependency. A small manufacturer, clinic, school, local retailer or professional office may experience network-device compromise as downtime, uncertainty or emergency contractor expense. It may not have in-house expertise to evaluate IOS XE release trains or compromise indicators. If its MSP cannot supply evidence, the customer is stuck choosing between trust and costly second opinions.

That uncertainty can become a business interruption even before any malicious traffic manipulation occurs. A customer may need to schedule emergency maintenance, replace devices, rotate credentials, review logs, notify leadership, pause remote management or reassure auditors. For an SME, those costs can be large relative to staff capacity. The fact that the vulnerable product is enterprise-grade does not mean every affected operator has enterprise-grade response capacity.

Contracts should reflect that reality. A managed-network contract should say who maintains exposure inventory, who receives vendor advisories, who can disable internet-facing management, who approves emergency changes, who preserves evidence, who reports indicators to the customer, who pays for emergency rebuilds, and what evidence the customer receives after closure. Without those terms, an incident like IOS XE becomes a scramble among vendor, MSP, customer, insurer and auditor.

Public agencies have a parallel duty. They often run distributed networks with legacy devices, procurement constraints and maintenance windows. They may also face public-service consequences if routing, wireless, emergency communications, school networks or municipal services degrade. The federal BODs do not automatically govern every local or foreign public entity, but the principles are transferable: know exposed management interfaces, prioritize known exploited vulnerabilities and document remediation. (CISA BOD 23-02, CISA KEV Catalog)

International advisories showed shared reliance

The IOS XE incident was global because Cisco devices are global. Government cyber agencies outside the United States issued or amplified warnings. Australia's cyber security center warned that exploitation of the vulnerability could allow a remote unauthenticated user to create a highly privileged account on the vulnerable system and take control of it. Canada's Cyber Centre published updates tracking Cisco's advisory and fix availability. (Australian Cyber Security Centre alert, Canadian Centre for Cyber Security advisory)

Those advisories matter because network-device vulnerabilities cross national boundaries faster than procurement systems do. A multinational company, a regional ISP, a school network and a city agency may all run IOS XE in different ways, with different release trains and support contracts. The same advisory becomes a different operational problem in each environment.

International amplification also reduces the chance that an incident is dismissed as one vendor's private customer notice. When multiple national agencies tell operators to act, the issue becomes part of public infrastructure hygiene. That has accountability consequences. Boards and public executives cannot plausibly say the risk was obscure after Cisco, CISA and other cyber agencies published guidance.

At the same time, global advisories do not solve local execution. An agency page cannot log into a customer's router, disable a web UI, review local users, install fixed software or rebuild a compromised device. It can only raise the signal. The last mile still belongs to asset owners and their providers.

The event therefore illustrates a familiar asymmetry: warnings are global, but recovery is local. Cisco can publish a fix. CISA can publish guidance. National agencies can amplify. Researchers can scan the internet. But a school district, SME or public authority still has to know which devices it owns, who administers them, how to close exposure, what outage window is acceptable and what proof of cleanup will satisfy its own risk decision.

The clean recovery record operators should have kept

A defensible recovery record for the IOS XE web UI event should be more concrete than "patched." It should begin with inventory: all IOS XE devices, models, release trains, roles, management addresses, management access paths, web UI state, internet exposure state and responsible owner. It should then document mitigation: HTTP and HTTPS server disabled or restricted where appropriate, access control applied, fixed software identified, maintenance window scheduled and emergency exceptions approved.

Next comes compromise assessment. The operator should record whether each device showed unexplained or newly created users, whether known indicators were present, whether logs showed suspicious access, whether AAA records aligned with expected administration, whether configuration changes appeared unauthorized and whether the device had to be rebuilt. The record should distinguish "not vulnerable," "vulnerable but not exposed," "exposed with no indicators found," "exposed with indicators," and "confirmed compromised."

Then comes restoration. Fixed software version, image source, checksum or integrity validation, configuration backup comparison, removal of unauthorized users, credential rotation, AAA review, SNMP and automation credential review, logging verification and post-change monitoring should be recorded. For high-value devices, a rebuild from trusted media may be more credible than in-place cleanup when compromise is suspected.

Finally, there should be customer and leadership communication. Executives need a summary that connects technical state to business risk. Customers of MSPs need device-specific evidence, not just a generic advisory link. Public agencies need a record suitable for auditors, insurers and oversight bodies. The difference between a good recovery and a weak recovery is often the evidence retained after the emergency passes.

NIST patch-management guidance reinforces the point that vulnerability remediation is a managed lifecycle rather than a single action. Organizations need inventories, prioritization, testing, deployment and verification. In an actively exploited network-device incident, that lifecycle compresses but does not disappear. (NIST SP 800-40 Rev. 4)

The incident also argues for recurrent exposure tests. A quarterly or continuous check for internet-exposed management services would have reduced surprise. A configuration-management system that flags ip http server or ip http secure-server on internet-facing devices would have reduced response time. Centralized AAA would have made unexpected local users easier to spot. These are not exotic controls. They are the quiet controls that become loud only when missing.

Configuration provenance deserves its own line in that record. A network device can pass a vulnerability scan and still be operating from a configuration whose origin is poorly understood. Operators should know whether the running configuration came from a standard template, an emergency change, an MSP exception, an inherited acquisition network or a local administrator's one-off fix. In the IOS XE case, provenance could explain why a web UI was enabled and reachable. Without that context, remediation may close the immediate exposure while leaving the organization vulnerable to the same pattern returning through the next template push or replacement device.

Provider evidence should be equally concrete. An MSP should be able to give a customer a dated list of affected and unaffected devices, the exposure state before mitigation, the commands or configuration changes used to close the management surface, the fixed software target, the compromise-assessment result, and any remaining exceptions. The customer does not need every packet capture or sensitive credential detail. It does need enough evidence to decide whether business continuity, cyber insurance notice, auditor communication or customer notification is required. A generic statement that "Cisco devices were reviewed" is not the same as a recovery record.

That record should also identify who approved the exposed state before the incident. In many networks, a management interface becomes reachable because of an old exception, a temporary troubleshooting change, a template inherited from a predecessor, or an outsourced support model that quietly normalizes broad access. Closing the exposure after a zero-day is necessary, but accountability requires learning why the exposure existed. If the reason is not captured, the same pattern can reappear when a replacement device is installed, a backup configuration is restored, or a support provider standardizes the next deployment.

The evidence gaps are themselves instructive

The public record does not provide a full victim count, a complete actor attribution, every implant detail, every affected hardware platform, every customer's exposure state or a universal recovery prescription. Some of that information may be unknowable publicly. Some may have been shared privately with affected customers or law enforcement. The absence should not be filled with speculation.

The most responsible public finding is narrower. Cisco and CISA documented active exploitation of IOS XE web UI vulnerabilities, with privilege 15 account creation, root escalation and implant writing. CISA urged disabling internet-facing HTTP Server exposure, hunting and upgrading. Fixed releases became available across release trains. The accountable consequences depend on local exposure, inventory and recovery.

That evidence boundary protects against two bad narratives. The first bad narrative says the whole event was simply Cisco's fault. That ignores customer and MSP control over internet-exposed management. The second bad narrative says the whole event was simply customers' fault for exposing management. That ignores Cisco's responsibility for the vulnerabilities, advisory quality, fix delivery and product design incentives.

The truth is less satisfying and more useful. Product defects and deployment exposure combined. Attackers exploited both. Good recovery required vendor fixes and operator discipline. Neither side's control was complete, but both sides had enough control to be accountable for their part.

The event also shows how hard it is to prove negative trust after management-plane compromise. A device may be patched, but can the operator prove there was no account creation? A user may be removed, but can the operator prove no configuration changed? An implant may disappear after reboot, but can the operator prove there was no later persistence? A public-facing status message rarely answers those questions. Evidence architecture built before the incident does.

Accountability follows the management plane

The management plane is where authority concentrates. It is where administrators authenticate, configurations change, users are created, services are enabled, logs are viewed and recovery begins. Leaving that plane reachable from the public internet creates a permanent wager: that authentication, code, configuration, monitoring and patching will all remain strong enough against every current and future exploit.

The IOS XE web UI incident showed that the wager can fail. Cisco's product had two previously unknown issues in the web UI chain. Customers and providers had exposed management interfaces. Attackers moved fast enough that mitigation and fix delivery became an emergency. Government agencies had to amplify guidance. Operators had to hunt for account creation and implants. SMEs had to rely on providers for answers.

The lesson is not to eliminate all remote administration. Modern networks need remote management. The lesson is to treat management access as privileged infrastructure with a smaller attack surface, stronger identity, network restrictions, logging, change control and continuous exposure review. Remote administration should be reachable through deliberate management paths, not through broad public internet exposure.

For Cisco, the continuing lesson is secure-by-design management-plane posture: make unsafe exposure harder, make dangerous configurations visible, make fixes traceable, make detection guidance actionable and make release mapping less confusing. For customers and MSPs, the lesson is asset and exposure truth: know what is running, know what is reachable, know who owns it, know how to disable it, know how to rebuild it and know what evidence will prove cleanup.

For public agencies and regulators, the lesson is that network-device management interfaces deserve the same visibility as headline application CVEs. A compromised router or switch can distort the evidence environment around other incidents. It can become a blind spot inside the response architecture. That makes management-plane exposure a continuity risk, not only an IT hygiene issue.

Cisco IOS XE's 2023 web UI exploitation record is valuable because it refuses a simple ending. Patches mattered. Hardening mattered. Advisories mattered. Inventory mattered. MSP accountability mattered. The implant mattered. The exposed interface mattered most because it decided which devices were reachable before defenders had perfect information.

The accountable conclusion is therefore practical. A network device should not have to be compromised before its owner discovers that a management web UI was open to the world. A vendor should not rely on customers finding every unsafe exposure after a zero-day has already landed. A provider should not tell a customer "we handled it" without evidence. In management-plane security, trust is not a feeling about a brand or a patch level. It is a record: exposure closed, compromise assessed, software fixed, device rebuilt where needed, and network authority restored with proof.