Paying a ransom may reduce immediate disruption, but it does not guarantee data deletion, prevent repeat targeting, or restore trust in compromised identities. Restoring without payment can preserve leverage and avoid funding the attacker, but it may extend downtime if recovery is incomplete. The practical difference is risk trade-off. Teams need tested recovery, clear legal input, and breach response discipline before deciding.
Why the payment decision changes the recovery problem
The decision is not just financial, it changes the recovery path. Paying can shorten the immediate pressure window if the attacker is willing to provide a decryptor or promise deletion, but that outcome is uncertain and often only partially under the defender’s control. Restoring without payment means the team owns the recovery timeline, which is slower if backups, rebuilds, or identity remediation are incomplete.
In practice, the key difference is whether the organisation is buying time from the attacker or relying on its own recovery capability. That distinction matters most when the incident has affected trusted identities, because compromised accounts, tokens, or admin paths can let the attacker re-enter even after systems are restored.
When identity compromise is part of the event, the right comparison is not ransom versus no ransom in the abstract, but attacker leverage versus verified restoration. A case study such as Caesars Entertainment Breach 2023, Scattered Spider shows why credential theft can turn a recovery decision into a trust decision about identity infrastructure as much as about files or hosts.
What paying can and cannot change
Paying may reduce immediate disruption if the attacker is cooperative, but it does not create a reliable guarantee. The decryptor may fail, stolen data may still be published, and the same access path may remain usable if compromised identities were not remediated. A payment can also create a false sense of closure when the real issue is that the attacker still has a foothold or the recovery team has not reestablished trustworthy access.
Restoring without payment has the opposite profile. It avoids transferring funds to the attacker and preserves negotiation leverage, but it depends on disciplined recovery, clean rebuilds, and identity resets that are often harder than simple file restoration. The operational burden is usually less about encryption itself and more about ensuring that the restored environment is not rebuilt on top of the same compromised trust relationships.
That is why recovery planning must treat identity and access as part of the restoration boundary. Identity lifecycle management is relevant here because compromised credentials, long-lived secrets, stale accounts, and orphaned access can survive the visible recovery and keep the incident alive.
How to decide between payment and restoration
The decision should be based on the quality of recovery evidence, not only on outage pressure. If backups are intact, the restoration path is tested, and privileged access has been reset or reissued, recovery without payment is usually the stronger control choice. If the team cannot verify clean restoration, then paying for speed may still leave the organisation exposed to repeat compromise or unfinished eradication.
Identity-driven attacks also change the decision because they often compromise the very controls used to recover. If the attacker has stolen administrative credentials, session tokens, or identity-provider access, then restoring data without rotating and validating those trust points can simply return the attacker to a functioning environment. A useful reference point is the Identity Threat Detection and Response guide, which frames identity compromise as a response problem, not only a detection problem.
For many teams, the cleanest decision rule is: if you cannot prove that the recovery environment is free of the attacker’s original access path, treat payment as a tactical choice, not a recovery outcome. If you can prove clean recovery and trustworthy access, restoration without payment is usually the better long-term posture.
Risk and Threat Considerations
An identity-driven attack creates a special recovery risk because the same identities used for business operations may also be the attacker’s easiest route back in. Paying does not necessarily remove that risk, and restoring without payment can fail if privileged access, federation trust, or shared secrets are still compromised. The underlying threat is persistence through stolen trust.
Failure mechanism: The attacker abuses compromised identities, sessions, or access paths to survive cleanup, even after encrypted systems are rebuilt or restored from backup.
Impact: The organisation can pay and still be re-extorted, or it can restore without payment and still suffer reinfection, downtime, or repeated loss of control over critical systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Restoring after identity compromise depends on rotating and controlling authenticators. |
| IA-2 — Identification and Authentication (Organizational Users) | Identity-driven attacks hinge on compromised user authentication paths. | |
| AU-6 — Audit Review, Analysis, and Reporting | Recovery decisions depend on evidence that attacker access has been removed or persists. | |
| Recommendation — Rotate compromised authenticators and revoke stale credentials before declaring recovery complete. Re-establish organizational authentication with newly trusted credentials and access paths. Review identity and access logs to confirm the attacker’s original entry path is closed. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Recovered environments fail when compromised or stale non-human identities are not removed. |
| NHI-07 — Long-Lived Secrets | Long-lived secrets can preserve attacker access across restoration or payment decisions. | |
| NHI-05 — Overprivileged NHI | Excess privilege increases the chance that stolen access can be reused during recovery. | |
| Recommendation — Offboard compromised non-human identities and revoke their access before reintroducing services. Replace long-lived secrets with short-lived credentials and enforce rotation after compromise. Reduce excess privilege so restored identities cannot recreate the compromise path. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Stolen valid accounts are a common persistence path in identity-driven attacks. |
| T1550 — Use Alternate Authentication Material | Stolen tokens, keys, or tickets can survive restoration if not explicitly revoked. | |
| Recommendation — Hunt and disable valid accounts used by the attacker before trusting recovery. Revoke alternate authentication material and verify sessions are invalidated during recovery. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account control is central when the incident depends on compromised identities. |
| Recommendation — Inventory, disable, and reissue affected accounts before resuming normal operations. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan is Executed | The question is about choosing and executing the recovery path after compromise. |
| Recommendation — Execute the recovery plan only after validating that the environment is clean and serviceable. | ||
Practitioner Guidance
What to verify: Before choosing payment or no payment, verify that backup sets are usable, privileged credentials have been rotated, and federated or SSO paths tied to the compromise have been re-established under new trust. If any of those are uncertain, do not treat restoration as complete.
Decision rule: If the attacker’s access path is still unknown, prioritise identity reset, containment, and recovery validation over the payment debate. If the organisation has tested restores and can prove the compromised identities are no longer valid, restoration without payment is usually the more defensible option.
Practitioner takeaway: The real recovery test is whether the environment can be made trustworthy again, because payment may shorten downtime but it does not, by itself, remove the compromised identity that enabled the attack.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
