Ivanti Connect Secure made VPN appliances a public-sector accountability surface

Summary

• Ivanti disclosed chained vulnerabilities affecting Connect Secure and Policy Secure, including CVE-2023-46805 authentication bypass and CVE-2024-21887 command injection, after researchers reported active exploitation.
• Volexity and Mandiant described attacker activity against Ivanti VPN appliances, including webshells, credential or configuration access, and persistence-oriented tradecraft.
• CISA issued Emergency Directive 24-01 for federal agencies, later requiring affected agencies to disconnect vulnerable products, export configuration, reset appliances, upgrade, and import clean configuration before returning them to service.
• The incident turned a VPN appliance into a governance surface: inventory, mitigation timing, integrity-check trust, rebuild thresholds, credential rotation, logging, and continuity planning mattered as much as patch availability.
• The public record supports a high-confidence finding that exposed remote-access appliances must be handled as potentially compromised systems after known exploitation. It does not prove every Ivanti customer was compromised or that every later remote-access incident stemmed from the same vulnerability chain.

The chain made remote access the first accountability question

Ivanti's public advisory for CVE-2023-46805 and CVE-2024-21887 described a vulnerability pair affecting Connect Secure and Policy Secure gateways. CVE-2023-46805 was an authentication bypass. CVE-2024-21887 was command injection. In combination, the issue allowed an unauthenticated attacker to reach command execution paths on vulnerable appliances. For a remote-access gateway, that is a severe control failure because the appliance sits at the exact boundary where outsiders are supposed to become authenticated insiders.

Volexity's report on active exploitation of the two zero-days said it observed exploitation in December 2023 and connected the activity to a suspected Chinese state-sponsored actor it tracks as UTA0178. Mandiant's analysis of suspected APT targeting Ivanti zero-days described post-exploitation tooling, webshells, credential access, and attempts to maintain access. Those reports made the incident more than a vendor advisory. They put real intrusion activity in the public record.

The accountability question therefore started before any customer opened a change ticket. Who had exposed appliances? Who had an owner for each appliance? Who could apply mitigations immediately? Who could verify whether the appliance had been compromised before mitigation? Who could disconnect remote access without disabling critical work? These are organizational questions, not only technical ones.

The difference matters. If a software library has a critical vulnerability, an organization may patch systems and monitor application behavior. If a VPN appliance has been exploited, the gateway itself may be the foothold. It can mediate access, hold secrets, and log only part of the truth. That makes trust harder to restore.

CISA made the risk an emergency operating order

CISA's alert, Ivanti Releases Mitigations for Connect Secure and Policy Secure Gateways, told administrators to review Ivanti's advisory and apply mitigations. The federal response then escalated. Emergency Directive 24-01 ordered federal civilian executive branch agencies to take specific actions for affected Ivanti products. CISA later updated the directive with additional requirements, including disconnecting affected products from networks, exporting configuration, performing a factory reset, applying updates, and only then importing configuration.

That sequence is important. It treats the appliance as possibly untrusted, not merely outdated. A factory reset before upgrade and clean configuration import is a different posture from "install patch and resume." It recognizes that a compromised appliance may retain attacker changes or artifacts that ordinary patching does not remove.

CISA's later joint advisory, AA24-060B, described exploitation of Ivanti Connect Secure and Policy Secure gateways and warned about post-compromise activity. The advisory is useful because it converted scattered vendor and researcher findings into an operational response model. It pointed defenders toward detection, hunt, credential, and rebuild concerns.

For public-sector continuity, the directive created a visible standard. Agencies could not say the matter was only a vendor issue. They had to know whether they used affected products, isolate or disconnect them when required, and restore them under a defined process. That is what accountability looks like when remote-access infrastructure supports public work.

The integrity checker became part of the trust problem

Ivanti provided an Integrity Checker Tool so customers could scan appliances for compromise indicators. That was necessary, but the public record shows why integrity checks need humility. Mandiant's later work on investigating Ivanti exploitation and persistence described activity that included attempts to evade detection and persistence mechanisms. CISA's advisory also warned that sophisticated actors could undermine confidence in appliance state.

This created a difficult governance problem. Customers needed a fast answer to the question "are we compromised?" The tool could help. But a clean tool result was not the same as proof of trustworthiness, especially if the attacker had already obtained appliance-level access. An integrity checker running on or against a potentially compromised system can miss modified artifacts, deleted evidence, or novel persistence.

That does not make the tool useless. It makes it one part of an evidence package. Customers needed to combine it with external logs, configuration review, network telemetry, webshell hunting, account review, credential rotation, and vendor or incident-response guidance. Where evidence was missing, caution had to rise.

The lesson extends beyond Ivanti. Every edge-vendor incident creates pressure to produce a simple green or red outcome. But compromised appliances resist simple outcomes. A meaningful assessment often has confidence levels: no evidence found with adequate logs, no evidence found with limited logs, evidence of suspicious access, confirmed compromise, or unable to determine. Those categories tell management more than a pass/fail scan.

Patch timing did not erase the exposure window

Ivanti's advisory path included mitigations first and patches later. CISA's January 31 alert noted security updates for multiple products. NVD records for CVE-2023-46805, CVE-2024-21887, CVE-2024-21893, and CVE-2024-22024 show the vulnerability cluster that defenders had to track as the situation evolved.

That evolution is the operational problem. A customer may have applied the first mitigation, then had to monitor for bypasses or new related vulnerabilities, then had to apply later updates, then had to decide whether to rebuild. Each step required asset inventory and change authority. A customer with one centrally managed appliance could move quickly. A customer with many appliances across business units, contractors, and legacy networks faced a different problem.

Patch timing also could not erase exploitation that occurred before the fix. If an actor accessed the appliance in December 2023, a January mitigation might stop the same path but not remove webshells, stolen credentials, altered configuration, or follow-on access elsewhere in the network. That is why the incident belonged to incident response as much as vulnerability management.

The accountable timeline is therefore not "advisory date to patch date" alone. It includes exposure before disclosure, mitigation time, evidence collection, suspicious activity review, credential and certificate actions, rebuild decisions, continuity impact, and after-action control changes. The customer that records only the patch date keeps the easiest metric and loses the harder evidence.

Inventory determined who could act

An emergency directive or vendor advisory is only useful if an organization knows whether it owns the affected product. Ivanti Connect Secure appliances can exist in headquarters environments, regional offices, acquired networks, contractor access paths, managed service portfolios, and legacy remote-access systems. Some may be internet-facing by design; others may be exposed by drift. The first operational question was therefore inventory.

Shadowserver's reporting on Ivanti Connect Secure exposure illustrates how external scanning can identify vulnerable or exposed systems at internet scale. External visibility is valuable, but it should not be the primary way a customer discovers its own VPN infrastructure. If a government agency or enterprise learns about an appliance from a third-party scanner, ownership records are already weak.

Good inventory includes product name, version, internet exposure, business owner, technical owner, managed-provider owner, user population, authentication dependencies, connected internal networks, logging configuration, backup state, and emergency isolation procedure. That may sound detailed. For a remote-access gateway, it is basic accountability. The appliance is not a commodity server. It decides who can reach the inside.

The Ivanti incident exposed the cost of inventory gaps. A missing appliance could remain exposed. An unowned appliance could miss mitigation windows. A locally owned appliance could lack central logs. A contractor-managed appliance could create a dispute about who approves shutdown. Those are governance failures that attackers can exploit without caring whose org chart caused them.

Credential scope was bigger than user passwords

Remote-access gateways handle more than usernames and passwords. They may store local administrator accounts, directory integration credentials, certificates, VPN session material, configuration backups, SAML or RADIUS settings, group mappings, split-tunnel rules, and access policies. If an appliance is compromised, the response cannot stop at a software fix.

The organization needs a credential map. Which directory accounts could the appliance use? Which service credentials were stored or reachable? Which certificates were present? Which local administrators existed? Which privileged users authenticated during the exposure window? Which downstream systems accepted sessions from the VPN? Without that map, credential rotation becomes either too narrow to protect trust or too broad to execute efficiently.

Mandiant's reporting on post-exploitation behavior gave defenders a reason to think about persistence and credential access as part of the same incident. CISA's emergency instructions reinforced that attitude by calling for reset and rebuild behavior rather than only patching. These are practical signals: if the appliance was exposed and compromise cannot be ruled out, identity controls need review.

This is where many organizations face cost pressure. Rotating credentials, certificates, and integration secrets is disruptive. It can break remote access, application connectivity, monitoring, and partner workflows. But leaving old secrets in place after possible appliance compromise may preserve the attacker's path. The responsible response sets pre-defined thresholds for rotation, so the organization is not negotiating under fear and fatigue.

Webshells turned the gateway into a persistence surface

The Ivanti incident became particularly serious because public researchers discussed webshells and post-exploitation tools, not only initial exploit mechanics. A webshell on a VPN appliance changes the shape of response. The attacker may no longer need to exploit the original vulnerability. The appliance itself becomes a managed foothold.

MITRE ATT&CK's Exploit Public-Facing Application and External Remote Services techniques capture the strategic pattern. The appliance is public-facing, and it provides remote access. Once the actor turns that device into a foothold, later activity may look less like a vulnerability event and more like authenticated or administrator-like behavior.

That is why appliance logs, external telemetry, and configuration baselines matter. Did the appliance start making unusual outbound connections? Did new files appear? Did web components change? Did administrator sessions occur at strange times? Did authentication events come from unfamiliar networks? Did the appliance communicate with internal systems it normally does not touch? These questions must be answered with evidence outside the compromised device wherever possible.

The public record does not mean every vulnerable appliance had a webshell. It means defenders had to treat that possibility as real. A mature response does not wait for certainty when the gateway has both exposure and known exploitation. It increases monitoring, narrows access, and chooses conservative trust decisions where evidence is incomplete.

Vendor accountability was about guidance quality

Ivanti's responsibilities included disclosure, mitigations, patches, tooling, customer communication, and coordination with agencies and researchers. That is a difficult operating position during active exploitation. The vendor has to move quickly while facts are changing. But the accountability standard is not perfection. It is whether customers received clear enough guidance to act safely.

Guidance quality matters in several dimensions. Customers need to know affected versions, exploit status, mitigation steps, patch timing, tool limits, how to collect evidence, when to disconnect, when to rebuild, which logs to preserve, and which secrets to rotate. They also need updates when new vulnerabilities or bypass concerns appear. Ambiguity pushes customers toward either underreaction or panic.

The Ivanti case shows why remote-access vendors should prepare response playbooks before the crisis. If a VPN appliance is actively exploited, a vendor should already have public language for appliance trust, external logging, configuration export, factory reset, rebuild, credential action, and managed-provider coordination. The harder the guidance is to draft under pressure, the more it should be prepared in advance.

Vendor accountability also includes product design. Secure defaults, safer administrative paths, stronger tamper evidence, independent logging, easier upgrades, and cleaner rebuild procedures all reduce customer harm when a vulnerability appears. A vendor cannot eliminate every future flaw. It can reduce the chance that every flaw becomes a trust crisis.

Customer accountability was about operational proof

Customers controlled deployment architecture. They decided whether appliances were internet-facing, how administrative access was restricted, how logs were exported, how identity was integrated, whether continuity alternatives existed, and how quickly mitigation could be applied. The vendor owns product security; the customer owns much of the operating surface.

The customer evidence package should answer simple questions. Which appliances were affected? Were they exposed? When were mitigations applied? Were patches installed? Were appliances disconnected where required? Were factory resets performed where appropriate? What did integrity checks show? What external logs were reviewed? Were credentials or certificates rotated? Did users lose access? Which business processes depended on the gateway? What changed afterward?

For regulated or public-sector customers, those answers should be auditable. The public does not need every technical detail, but oversight bodies should not accept a one-line "we remediated." The risk involves remote access to public or sensitive systems. The evidence has to match the stakes.

The same applies to enterprises. A board or risk committee should ask whether the organization can prove appliance trust after known exploitation. If the answer relies on a clean scan without supporting logs, the confidence should be lower. If the answer includes external logs, configuration comparison, credential action, and rebuild where needed, the confidence should be higher.

Managed providers needed a clear division of labor

Many customers did not manage their Ivanti appliances alone. Remote-access infrastructure may be run by managed security providers, outsourced IT, regional teams, defense contractors, or service integrators. During an exploited VPN emergency, that layered ownership can either accelerate response or create delay.

Contracts should specify who watches vendor advisories, who applies emergency mitigations, who can disconnect service, who communicates to users, who collects evidence, who runs integrity checks, who performs factory reset, who imports configuration, who rotates credentials, and who writes the after-action report. Without that division, every step can become a negotiation.

Managed providers also need portfolio-level visibility. If a provider manages many customer appliances, it should be able to identify all affected instances quickly, prioritize high-risk environments, and tell each customer what happened to its own appliance. A generic assurance that "we are aware of the issue" is not enough when active exploitation is public.

The customer should demand evidence, but the provider should not wait to be asked. A provider that manages an internet-facing VPN gateway is managing a trust boundary. It owes customers clear status, specific remediation state, and confidence-rated findings. That is part of the service, not an optional report.

Continuity made disconnection a hard but necessary control

CISA's directive showed that disconnecting a VPN appliance may be the correct security decision. It can also be a painful continuity decision. Remote staff may lose access. Administrators may lose normal maintenance paths. Contractors may not reach systems. Agencies may have to shift to alternate access under pressure.

This is why continuity planning belongs in the same risk register as VPN security. An organization that cannot disconnect a vulnerable appliance has allowed a single product to become a continuity choke point. A mature organization has tested alternatives: separate administrative access, emergency bastion hosts, zero-trust access paths, local continuity procedures, manual processes, or planned service degradation.

The continuity question is not whether every user can work normally during an emergency shutdown. The question is whether critical work can continue safely enough. Public agencies, hospitals, utilities, and financial institutions need a tiered answer: which functions must continue, which can pause, which need emergency access, and which require manual fallback.

If that plan does not exist, business pressure will push teams to keep the vulnerable appliance online, create unsafe temporary access, or return it to service before trust is restored. The Ivanti incident made that tradeoff visible. Security and continuity were not separate departments. They were the same decision.

What evidence would change the assessment

The assessment would be less severe for an organization that can show the appliance was not internet-facing, was not on an affected version, was mitigated before exposure, had complete external logs, passed integrity checks with supporting telemetry, and had credentials scoped and rotated where needed. It would also improve if the organization performed factory reset or rebuild under a documented threshold and tested remote-access alternatives.

The assessment becomes more severe where appliances were exposed, mitigation was delayed, logs were missing, integrity-check results were treated as absolute proof, credentials were not reviewed, and remote-access continuity forced early return to service. It becomes more severe again where managed providers could not identify affected customer appliances quickly.

For Ivanti as the vendor, the assessment would improve with clear root-cause learning, stronger secure defaults, improved tamper evidence, easier rebuild processes, better customer evidence tooling, and guidance that treats appliance compromise as an incident-response problem. It would worsen if similar classes of exploited remote-access flaws recur without visible product and process changes.

The current public evidence supports a bounded conclusion. Ivanti products were actively exploited through serious vulnerabilities, public authorities treated the risk as urgent, and remote-access appliances had to be handled as potentially compromised infrastructure. The public evidence does not support claiming uniform compromise across all customers. It does support a higher accountability standard for every exposed deployment.

KEV listings change the governance clock

CISA's Known Exploited Vulnerabilities catalog entries for CVE-2023-46805 and CVE-2024-21887 matter because they move a vulnerability from general risk management into exploited-risk governance. For covered federal agencies, KEV has formal operational consequences. For everyone else, it is still a public signal that the issue has crossed from theoretical exposure into active abuse.

That signal should change meeting behavior. A critical vulnerability in a remote-access appliance should not sit only in a patch-management queue once it is in KEV. It should trigger incident command, asset confirmation, business-owner notification, managed-provider escalation, identity-team involvement, and executive risk visibility. The reason is simple: exploited remote access can become an entry point into the organization before the patch meeting happens.

KEV also helps reduce a common excuse. Organizations sometimes treat vendor advisories as one item among many, ranked by CVSS score and planned maintenance windows. Known exploitation changes the priority. A VPN gateway that may already have been used by threat actors cannot wait for a comfortable maintenance cycle without a documented risk acceptance. If remote access is too important to disrupt, that is exactly why the appliance deserves emergency attention.

The catalog also creates a record for oversight. Boards, auditors, insurers, and regulators can ask whether the organization had KEV intake, how quickly the Ivanti entries were matched to inventory, whether ownership was clear, and why any exposed appliance remained online. That makes the accountability surface durable. It is not only what the security team knew. It is what the institution did after a public exploited-vulnerability signal existed.

The practical metric is time-to-truth. How long did it take to know whether the organization had affected Ivanti products? How long to know whether they were exposed? How long to know who owned them? How long to decide mitigation, disconnection, reset, or replacement? Time-to-patch is important, but time-to-truth decides whether management was governing the situation or waiting for someone else to make it legible.

External evidence must be designed before the emergency

The UK's NCSC guidance on secure system administration reinforces a principle that applies directly to VPN appliances: privileged systems should be administered through controlled, monitored, and auditable paths. In the Ivanti case, the appliance itself was the suspected target. That means administrative records, configuration changes, and remote-access events should not depend only on the appliance remaining honest.

External evidence begins with log export. Authentication events, administrative logins, configuration changes, system events, web requests where available, and network flows should be copied to systems with independent retention. The logs should be time-synchronized and correlated with identity records, endpoint telemetry, and change-management tickets. If a responder cannot reconstruct what happened before the advisory, the organization is already making decisions in a fog.

Configuration evidence is just as important. The organization should have known-good backups with integrity checks, documented expected files, and a way to compare current state against baseline. A factory reset followed by clean configuration import is only clean if the configuration itself is understood. If no one knows whether the backup already contains unauthorized changes, the rebuild process may reintroduce risk.

External evidence also changes communication. A customer can tell leadership "we found no evidence of compromise in externally retained authentication and configuration logs covering the exposure window" with more confidence than "the appliance integrity check passed." Both statements may be true, but they are not equally strong. The first identifies evidence scope. The second may hide evidence limits.

This is the difference between security tooling and accountability evidence. A tool can help a team act. Evidence helps an institution justify trust. For remote-access infrastructure, both are required because the decision affects people who depend on the gateway but do not manage it.

Secure-by-design applies to the appliance lifecycle

CISA's Secure by Design framing is relevant because remote-access appliances should not rely on customers assembling every safety property after deployment. Vendors can reduce customer failure by shipping safer defaults, clearer warnings, stronger logging, tamper-resistant evidence, easier patching, and cleaner rebuild workflows. Customers still have duties, but product design can make the safe path easier than the dangerous one.

For an Ivanti-like remote-access product, secure-by-design expectations should cover the whole lifecycle. Before deployment, administrators should be pushed toward restricted management interfaces, strong authentication, external logging, and documented backup. During routine operation, the product should make exposure, version age, and risky settings visible. During emergency response, it should offer precise guidance about evidence collection, reset, upgrade, configuration import, and credential actions. After restoration, it should help customers verify state and reduce recurrence.

The same lifecycle view should apply to customer deployment. Buying a VPN appliance is not a one-time procurement event. It creates an ongoing trust dependency. The organization needs owners, patch windows, escalation paths, logs, continuity alternatives, and retirement plans. If a product remains in service after teams stop actively managing it, the appliance becomes governance debt.

The Ivanti incident is useful because it shows how design and operation interact. A vendor flaw created the exploit path. Customer exposure and evidence practices shaped the consequence. Public authorities set minimum emergency actions. Managed providers influenced speed and visibility. None of those layers alone explains the whole outcome.

That layered accountability is often uncomfortable, but it is accurate. A vendor cannot say customers own everything after deployment. A customer cannot say the vendor owns everything after a flaw is found. A provider cannot say the customer owns the risk while the provider controls the appliance. Secure-by-design thinking forces every party to name its control surface before the next emergency.

Procurement should buy recovery evidence, not only access

Public agencies and large enterprises often procure remote-access products for availability, security features, support, and price. The Ivanti record suggests they should also procure evidence and recovery obligations. The contract should ask what happens if the appliance is actively exploited: how quickly the vendor publishes guidance, how support queues are prioritized, how managed providers coordinate with the vendor, and what evidence customers can receive.

For managed deployments, the contract should go further. It should define external log retention, customer access to logs, emergency disconnection authority, approval bypasses for exploited vulnerabilities, rebuild or factory-reset procedures, credential-rotation support, customer-specific status reporting, and post-incident review. A customer that cannot obtain its own evidence from a provider cannot close its own incident responsibly.

Procurement teams should also test continuity assumptions. If the product provides the main remote-access path, the buyer should know how the organization works when that path is down. That test should include technical access, help-desk load, user communications, legal obligations, and business process triage. A contract that buys uptime but not safe shutdown leaves the customer trapped when the right security control is disconnection.

This is especially important for public-sector bodies. Citizens rarely know which appliance protects the agency network. They do know when services fail, records are exposed, or emergency response slows. Public procurement should therefore treat appliance trust as part of public-service continuity. A cheap or familiar VPN product is not enough if the agency cannot prove its state after exploitation.

The buyer's evidence requirements can improve the market. Vendors and providers respond to what customers demand. If customers ask only for access features and support hours, recovery evidence remains secondary. If they demand appliance trust, log export, rebuild playbooks, and post-exploitation support, those capabilities become competitive requirements.

The language of remediation should be precise

One of the most common public mistakes after exploited infrastructure incidents is vague remediation language. "Mitigated" can mean a workaround was applied. "Patched" can mean software was updated. "Reset" can mean credentials changed or a device was factory reset. "No evidence of compromise" can mean strong evidence was reviewed or weak evidence found nothing. "Restored" can mean a service is reachable, not that trust is complete.

The Ivanti incident demands more precise language. An appliance can be mitigated but not fully patched. Patched but not investigated. Investigated but with missing logs. Reset but with uncertain configuration. Rebuilt but with unrotated secrets. Restored but dependent on a continuity workaround. Those distinctions are not pedantry. They are how managers avoid false confidence.

Public statements do not need to expose sensitive details, but they should avoid compressing different states into one reassuring verb. Internal records should be even more precise. They should mark exposure status, mitigation status, patch status, integrity-check status, log-review confidence, credential action, rebuild state, return-to-service approval, and residual risk. That record becomes the basis for future audits and future emergencies.

Precision also protects vendors and providers when they did the work well. A provider that can say it disconnected affected appliances, exported configuration, reset devices, applied updates, imported reviewed configuration, rotated credentials, and preserved logs should get more credit than one that says "all systems remediated." Specificity builds trust because it names the controls.

The final benefit is learning. If every response is recorded as "patched," the organization cannot compare incidents. If one response required emergency shutdown, another required rebuild, and another required credential rotation, the organization can improve architecture where pain was highest. The Ivanti case should therefore push institutions to write better incident states, not only faster ticket closures.

Oversight should read the incident as a control test

Boards, audit committees, public inspectors, and agency leaders do not need to understand every exploit detail to ask the right questions. They need to ask whether remote-access inventory was complete, whether known-exploited vulnerability intake worked, whether the organization could disconnect a critical gateway, whether evidence survived outside the appliance, and whether return-to-service was based on documented trust.

Those questions make the incident legible at governance level. A technical team may report that mitigations were applied quickly. Oversight should ask whether any appliance was discovered late. A provider may report that customer access was restored. Oversight should ask whether customer-specific logs and rebuild records exist. A business owner may report that remote staff kept working. Oversight should ask whether that continuity depended on unsafe exceptions.

The point is not to second-guess every engineering decision after the fact. It is to prove that exploited remote access is managed as an institutional risk. VPN appliances sit between public networks and internal systems. Their failure can affect data protection, public service continuity, incident response, and contractual trust. That is enough to justify oversight attention beyond the security operations center.

This is also how organizations avoid repeating the same incident with a different product name. The next exploited edge device may come from another vendor and use another CVE. The governance test will be similar: know the asset, isolate it, preserve evidence, rotate secrets, rebuild when trust is uncertain, and keep critical work running safely.

The accountability test

The Ivanti incident should be judged through seven controls.

First, inventory: could the organization identify every Connect Secure and Policy Secure appliance, version, owner, exposure path, managed-provider relationship, and dependent user group within hours?

Second, mitigation and patch timing: did it apply Ivanti mitigations and later updates quickly, and did it track new related CVEs as the advisory evolved?

Third, isolation: where required or prudent, did it disconnect vulnerable appliances rather than leave remote-access convenience ahead of trust?

Fourth, evidence: did it preserve external logs, run integrity checks, review configuration, hunt for webshells or persistence, and document confidence levels rather than relying on one scan result?

Fifth, credential response: did it rotate or scope administrative credentials, VPN credentials, certificates, and integration secrets when compromise could not be ruled out?

Sixth, rebuild discipline: did it define when factory reset, reimage, or replacement was required before returning an appliance to service?

Seventh, continuity: did it have safe alternate access paths so public or business operations could continue without rushing an untrusted gateway back online?

The final finding is plain. Ivanti Connect Secure became a public-sector accountability surface because a remote-access product failure touched government directives, active exploitation, appliance trust, and continuity. The attacker owns the intrusion. Ivanti owns product security, disclosure, tooling, and guidance. Customers and managed providers own deployment, evidence, rebuild, credential, and continuity decisions.

The responsible response is not "patched." It is "we know what was exposed, what happened, what evidence survived, which secrets changed, which devices were rebuilt, and why the restored access path can be trusted."

Typography

Typography is the art and technique of arranging type to make written language legible, readable, and visually appealing. It involves selecting typefaces, point sizes, line lengths, line-spacing, and letter-spacing.

• Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
• Key elements include font selection, kerning, tracking, and leading.
• Good typography enhances readability and conveys mood or tone in design.