A blockchain infrastructure provider suspects a compromised credential with access to production. What must the response prioritise, and what capability determines how well it goes?

The priority order

Contain, preserve, investigate, recover — and the order matters because the instinctive action often destroys the evidence needed for the rest.

• Contain first. Revoke the credential, rotate what it could reach, and cut network paths. Speed matters more than precision here: over-revoking causes an outage, under-revoking leaves the attacker inside, and the first is recoverable while the second is not.
• Preserve before remediating. Snapshot affected systems, capture memory where feasible, and export logs to a location the attacker cannot reach. Rebuilding a compromised host destroys the evidence of what was done — and the question "what did they access" will be asked by customers, regulators and lawyers.
• Investigate scope using the audit trail: which credentials, which resources, which time window, what was read and what was changed.
• Recover by rebuilding from known-good rather than by cleaning, since a cleaned host is a host you hope is clean.

The capability that determines how well it goes

Whether you can answer "what did this credential access" from logs that the attacker could not modify.

That capability is built long before the incident: comprehensive access logging, logs exported outside the trust boundary in real time, immutable retention, and a credential model where each workload has its own identity so access can be attributed at all.

An organisation with shared credentials and local logs cannot answer the scope question, and the honest consequence is that the response assumes the worst — full rotation, full rebuild, and a customer notification that says "we cannot rule out".

The specific complication in this domain

Some actions are irreversible. A transaction submitted cannot be recalled, so containment must be faster than the attacker's ability to act, and the design should include a tested emergency halt for value-transferring operations that stops within seconds.

Invoking that halt is itself disruptive, which is why the decision authority and the threshold must be agreed in advance — during an incident there is no time to negotiate who may take the platform's most consequential action.

The follow-through that is usually missed

The customer and regulatory communication, drafted in advance for each severity. Writing it during the incident produces either silence or a statement that is later shown to be wrong, and in this domain both are more damaging than the incident.