On September 9, CISA added three actively exploited security-appliance vulnerabilities to its Known Exploited Vulnerabilities catalog. The affected products included Citrix NetScaler, several Fortinet products, and Cisco’s firewall-management platform.

Each entry came with two instructions for federal agencies: apply the vendor’s fix and perform forensic triage. The deadline was September 12, only three days after CISA added them.

On September 14, CISA added a Cisco Secure Email Gateway vulnerability with the same requirements. The deadline was September 17.

Those deadlines apply to federal agencies, not Iowa businesses. The reasoning still matters for a law firm or CPA office. When attackers are already exploiting a flaw, installing the patch may close the entry point. It does not tell you whether someone used it before you closed it.

What the patch does

A security patch changes vulnerable software. If the vendor’s fix works and the update is installed correctly, future attempts to exploit that flaw should fail.

That is important, but it only addresses what happens next.

Suppose a vulnerable firewall or remote-access appliance was reachable from the internet for ten days before the firm patched it. An attacker may have used that window to create an account, change a configuration, steal credentials, or establish another way back in. Updating the original software does not automatically reverse those actions.

The patch also does not answer whether data left the network. It does not show which administrator sessions occurred during the exposure window. If the device was rebooted or its logs were overwritten during the update, some of the evidence needed to answer those questions may disappear.

This is why CISA’s instructions separated remediation from forensic triage. One closes the vulnerability. The other looks for evidence that the vulnerability was used.

Why security appliances need extra attention

Firewalls, VPN gateways, email-security systems, and remote-access appliances sit in sensitive positions. Many are reachable from outside the office by design. They also handle authentication, network traffic, or administrative access.

That makes them useful targets. An attacker who compromises an employee laptop still has to work toward the rest of the network. An attacker who compromises the device controlling remote access may start much closer to the systems they want.

These appliances can also fall outside ordinary workstation patching. Nobody sees a pop-up asking to restart the firewall. Updates may depend on an IT provider noticing the advisory, checking the exact model and software version, scheduling downtime, and confirming the upgrade worked.

We have written about the same concentration of access in remote-management platforms. The tool trusted to manage or protect the environment can become a valuable path into it. That does not make the tool unsafe by default. It means the firm needs to know who owns its maintenance and what happens when a flaw is under active attack.

When an update becomes an incident review

Every software vulnerability does not require a full forensic investigation. A flaw in a product the firm does not own is irrelevant. A vulnerable device that was offline, isolated, or updated before exploitation began may need little beyond confirmation and documentation.

The response changes when several facts line up:

The firm runs an affected product and version.
The vulnerable service was exposed to the internet.
CISA or the vendor confirms active exploitation.
The device was exposed during the known attack window.
Exploitation could provide administrative access or control of the device.

At that point, “we installed the update” is an incomplete answer.

A reasonable first review starts by preserving available logs before they roll over. The IT team should identify when the device became vulnerable, when it was patched, and whether the affected service was reachable from outside. It should review administrator logins, newly created accounts, unexpected configuration changes, and remote sessions during that period.

If the device stored credentials, certificates, API keys, or other authentication material, the team may need to rotate them. It should also check the systems the appliance could reach, because an attacker may have moved away from the original device before the patch arrived.

The exact steps depend on the product and what the vendor reports about the exploit. The point is to make the decision deliberately instead of assuming the update erased the risk.

Questions your firm should ask

The managing partner or office administrator does not need to interpret vulnerability advisories. Whoever manages the technology should be able to answer:

Do we use any of the affected products or versions?
Was the vulnerable service reachable from the internet?
When did the vendor release a fix, and when did we install it?
Did we preserve and review logs from the exposure period?
Did the vendor or CISA publish indicators of compromise?
Were any accounts, credentials, or certificates rotated?
What evidence shows the device is both patched and free of known compromise?

If the first answer is “we do not use that product,” the issue can be closed quickly. If the device was affected and exposed, the remaining questions matter.

Keep the record

The final step is documentation. Record the affected asset, the version before and after remediation, the time the patch was installed, the exposure assessment, and the results of the compromise review.

That record helps with cyber-insurance questions and gives the firm a timeline if related activity appears later. It also shows whether the incident process worked: the advisory reached the right person, the device was identified, the update happened, and someone checked for signs of earlier access.

Patching quickly is still the right first move. Stopping there can leave the firm with a fixed appliance and an attacker who already found another way in.

If your vulnerability process ends when the patch installs, Artech can help you add the exposure and compromise checks that should come next.