When ransomware hits, an organization hands the keys to people it may have met that morning. Incident responders, recovery firms, negotiators and IT contractors get administrator credentials, remote access and sometimes a badge to the server room, at the moment leadership is least able to scrutinize them.

Three developments last week show why that access deserves the same governance as any other privileged account.

Three cases in one week

On October 7, the Justice Department announced charges against the owner of MonsterCloud, a Florida ransomware remediation company: "two counts of wire fraud and one count of wire fraud conspiracy." In one example from the indictment, he "made a ransom payment of approximately $236,000 and charged the client approximately $380,000." BleepingComputer reports that, according to the U.S. Attorney's Office, he pleaded not guilty. The Justice Department's own release notes that "an indictment is merely an allegation."

On October 8, a Canadian ransomware-negotiation executive was arrested in Pennsylvania on cyber extortion and conspiracy charges while attending a cyber-insurance conference in Philadelphia, according to federal court records reported by KrebsOnSecurity, with further reporting from BleepingComputer and Nextgov. Reports citing unnamed sources connect the arrest to the FBI's investigation of ShinyHunters. The complaint is sealed, and Nextgov reports that his "specific alleged conduct, including any role in the FBI intrusion linked to ShinyHunters, has not been publicly established." He is presumed innocent.

The third case involves the FBI's own vendor. CNN reports that FBI cyber official Brett Leatherman said a contractor managing the bureau's jobs portal failed to update software "explicitly issued to secure the platform," and that the FBI "removed the contractor."

Two of these are allegations, not findings. The third is the FBI's own account of a vendor that missed a security update. Read together, they make one point: the third parties trusted with privileged access before, during and after an incident are part of the attack surface.

In late September, after Dutch authorities arrested an alleged leader of ShinyHunters, Leatherman, assistant director of the FBI's Cyber Division, said the suspect and his alleged co-conspirators had "breached more than 140 organizations and collected at least $70 million in extortion payments since last year," as reported by Nextgov. BleepingComputer reports the group often uses "stolen credentials, authentication tokens, phishing, and social engineering." Every one of those methods targets the same thing a trusted vendor already holds: valid access.

When the vendor is the outage

Vendor risk is not only about who gets in. It is also about who an organization cannot operate without.

On October 9, a cyberattack on U.S. Next, the website host for Madison County and 68 other Mississippi government websites, caused an outage, according to WAPT. Madison County's administrator said a temporary splash page would let customers keep paying fees, and WLBT reported that some services, including land records and ticket payments, were restored hours later. DysruptionHub reported that the attack also disrupted U.S. Next's email services. County officials say no data was compromised, and the type of attack has not been confirmed.

One provider, dozens of public bodies, one shared point of failure. The county's quick workaround is the part worth copying.

The converged lens

Incident vendors rarely need only a login. Forensic teams image drives on site. Recovery crews work in server rooms and network closets. Contractors rebuild systems at the facility. That means the same third party may hold a VPN account, a domain administrator credential and a facility badge at the same time.

Those three can be approved by three different owners: IT, facilities and security. During a crisis, approvals can get compressed, temporary access can be granted in a hurry, and nobody may own the moment when all of it should be taken back. A vendor badge that still opens the server room a month after the incident closed is the same problem as a vendor account that was never disabled.

Treat incident-vendor access as one decision with one owner, covering both logical and physical access, with one expiration date.

What practitioners should do

Vet incident vendors before the incident. Select response, recovery and negotiation firms on a calm day. Check references and ownership, understand how they are paid, and understand how they handle any payment made on the organization's behalf. Legal and procurement own the contract terms; security owns the access model.

Follow the money. Require itemized records of any payment a vendor makes on the organization's behalf, so the amount paid and the amount billed can be compared.

Pre-build vendor access. Create dedicated, named accounts for retained vendors in advance, disabled until needed. No shared administrator credentials. Require phishing-resistant MFA and log every session.

Put an expiration on everything. Every vendor account, API key and badge issued during an incident gets an end date. Closing the incident means revoking that access and collecting the badges, then reviewing the access list against what was issued.

Escort and log on-site work. Vendors in server rooms, network closets and data centers should have a named employee sponsor, with entry and exit logged.

Make patching a contract obligation, then verify it. If a vendor maintains a platform, applying security updates should be a stated duty with evidence on request. Trust, but check.

Map single-vendor dependencies. Identify the providers whose outage would stop public-facing or operational services. For each one, document a manual workaround and an out-of-band way to reach the vendor when its email is down too.

Rehearse it. Include vendor onboarding and offboarding in incident response tabletop exercises. The first time an organization grants emergency access to a recovery firm should not be during a real incident.

Bottom line

The people called in on the worst day get the access nobody else gets. Last week, two incident-industry figures were charged and the FBI removed a contractor over a missed update. None of that proves a pattern of misconduct, and both charged men are presumed innocent. It does show that third-party access needs to be governed as carefully as the systems it protects, before the phone rings.

PSG Security Watch is published by Panoptic Security Group.

Sources: U.S. Department of Justice, https://www.justice.gov/opa/pr/known-cybersecurity-expert-and-owner-florida-ransomware-remediation-company-charged ; Indictment, No. 26-CR-271 (E.D.N.Y.), paragraph 15, posted by the U.S. Attorney's Office, https://www.justice.gov/usao-edny/media/1464771/dl?inline= ; Nextgov/FCW (Sept 29), https://www.nextgov.com/cybersecurity/2026/09/fbi-warns-shinyhunters-members-come-forward-after-alleged-leaders-arrest/416302/ ; BleepingComputer, https://www.bleepingcomputer.com/news/security/ransomware-recovery-ceo-charged-over-secret-ransom-payments/ ; BleepingComputer, https://www.bleepingcomputer.com/news/security/cyber-exec-arrested-in-case-allegedly-tied-to-shinyhunters-hackers/ ; Nextgov/FCW, https://www.nextgov.com/cybersecurity/2026/10/cybersecurity-executive-who-helped-hacking-victims-arrested-federal-extortion-charges/416545/ ; KrebsOnSecurity, https://krebsonsecurity.com/2026/10/fbi-arrests-founder-of-ransomware-negotiation-firm/ ; CNN via KDRV, https://www.kdrv.com/news/social/fbi-arrests-cybersecurity-executive-and-ransomware-expert-in-major-hack-on-agents-data/article_40847738-aef4-5492-bf60-e7193bf9a06b.html ; WAPT, https://www.wapt.com/article/cyberattack-disrupts-madison-county-website-and-almost-70-others-in-mississippi/74100614 ; WLBT, https://www.wlbt.com/2026/10/09/madison-co-website-down-following-cyber-attack-host-company/ ; DysruptionHub, https://dysruptionhub.com/incidents/profiles/u-s-next-2026-01/

‍