Cloud Services Operational Explainer

What should I do if a cloud account may be compromised?¶

Treat suspected cloud-account compromise as an evidence problem and a containment problem at the same time.

A password reset may be necessary, but it is rarely enough on its own. Existing sessions, delegated applications, recovery changes, service accounts or administrator roles may survive it.

The working principle

Preserve how access currently works, contain the routes that should not remain, then verify what actually stopped.

Capture the account state before changing it¶

Start by fixing the account, tenant, service and likely time range.

Then preserve the records that explain how control may have changed:

sign-ins;
active sessions and tokens;
trusted devices;
recovery and MFA changes;
connected applications;
API credentials;
administrator or role changes;
forwarding and sharing rules; and
audit events around the suspected compromise.

A useful account snapshot might look like this:

Pre-containment snapshot

Account: dave@northstar.exampleActive sessions: 3New application consent: APP-441Recovery method added: 2026-09-18 07:52 UTCExternal forwarding rule: enabled

That snapshot gives you something to compare with the post-containment state.

Work out every route that may still provide access¶

Do not reduce compromise to “someone knows the password”.

Possible continuing routes include:

Route	Why it matters
Existing browser session	May continue without another password entry
Refresh token	Can renew application access
Connected application	May act through delegated permission
Service account / API credential	May operate independently of the user's interactive login
New administrator	Can retain control even after the original password changes
Recovery method	Can help re-establish access later

What signs may indicate cloud-account compromise? helps identify the pattern before containment.

Contain in a deliberate sequence¶

The exact controls depend on the provider and organisation, but the investigative sequence is stable:

PreserveCapture current state and volatile recordsKnow what access existed before intervention.

RestrictRemove hostile or unnecessary authorityCredentials, sessions, apps, roles, links or keys.

RecordLog each control and timeContainment itself becomes part of the event history.

VerifyCheck what survivedLook for continuing sessions, automation or alternate access routes.

A password reset, session revocation, application removal and key rotation do different jobs. Record them separately.

Verify containment rather than assuming it¶

After the change, ask:

did the suspected session end;
did the application lose access;
did the forwarding or sharing rule disappear;
were unauthorised roles removed;
did new activity continue; and
did another account or device route remain active?

How should I document cloud-account containment? covers the evidential record of those interventions.

The practical point is: contain the account by access route, not by ritual. Preserve the pre-change state, remove the relevant authority and prove what actually stopped.