How attackers stay in
Changing the password was not enough
Suppose that on Day 2, when the alert fired, Cedar Inc. had simply reset Riley's password and moved on. The password the attacker captured through the relay page would stop working. Almost nothing else the attacker set up the day before would.
By then the attacker had registered their own authenticator app on Riley's account at 09:20, approved a third-party app called Invoice Sync with permission to read and send Riley's mail at 09:31, and added a mail rule at 09:40 that forwards messages containing "invoice". None of these depends on Riley's password. The authenticator is a sign-in method in its own right, Invoice Sync holds its own grant, and the mail rule runs on the mail server without anyone signing in.
Keeping access after the original way in has been closed is persistence, and each separate means of keeping it is a foothold. Attackers add footholds early, often within minutes of getting in, because they expect the first way in to be found. The diagram shows common footholds around a taken-over account and whether each one survives a password reset.
A second way back in
The most direct foothold is another sign-in method. An authenticator the attacker enrolls belongs to them, and depending on the service it can satisfy the second step whenever they learn the next password, prove identity in a self-service password reset, or complete a sign-in on its own. A passkey the attacker registers needs no password at all.
Adding a method is supposed to need proof that the person adding it controls the account now, as Enrollment, replacement, and recovery describes. At Cedar, that proof was a recent sign-in, which a stolen session passes easily.
Recovery contacts give the same result one step removed. If an attacker replaces the recovery email address or phone number, the next "forgot password" request goes to them, and they can reset the password again after the owner does. This is why changing a recovery contact should notify the old one.
App passwords are separate passwords that some services issue for older mail and calendar programs that cannot complete MFA. They skip the second factor by design. Some services cancel them when the main password changes, while others keep them until someone deletes them, so a defender has to check rather than assume.
Access that outlives the session
Sessions end and access tokens expire, but some access is built to last. When the attacker approved Invoice Sync at 09:31, Cedar's identity provider recorded a grant and gave the app a refresh token, which it can exchange for new access tokens without anyone signing in, as Giving another application limited access explains. The grant connects the app to Riley's account. It does not depend on Riley's password or on the session that approved it.
For honest apps that is the point: a calendar sync should not break every time someone changes their password. It also means that a grant an attacker approved keeps working after the owner recovers the account, until the grant is revoked along with the refresh tokens issued under it. Some providers end refresh tokens when a password changes, but a defender cannot rely on that without checking how their provider behaves.
The same is true of a mail or chat app signed in on the attacker's own device. It holds a refresh token of its own and can keep fetching new mail long after the session in the browser has ended. Revoking access and sharing security events follows how each of these kinds of access is ended.
Credentials added to applications
Applications have credentials too. An integration that archives every mailbox, or that creates accounts when the HR system hires someone, signs in with its own client secret or key, using a flow such as the client credentials grant. Most platforms let an application hold more than one credential at once, so that a new one can be added before the old one is removed.
An attacker with the right to manage an application can add a credential of their own. From then on, they can act as that application, with whatever permissions it already holds, from anywhere. Resetting a person's password, removing their methods or even disabling their account does nothing to it, because no person signs in. The change also looks like routine maintenance, since adding a new secret is exactly what a planned rotation does.
Riley's finance account had no right to manage applications. An administrator's account usually does, which is why administrators draw attempts like the refused call to Cedar's help desk. The record to watch for is a credential added to an application by someone who does not normally maintain it, followed by the application signing in from a network it has never used. Rotating client credentials shows what a planned change looks like, which makes an unplanned one easier to spot.
Quiet configuration changes
Some footholds are not credentials at all. The rule the attacker added to Riley's mailbox at 09:40 forwards every message containing "invoice" to an address outside Cedar. It needs no session, no token and no password. It runs on the mail server each time a matching message arrives, and it keeps running after every credential on the account has changed. Rules that move or delete messages work the same way, and can hide a security notification from the person it was meant for.
With administrative access, configuration changes reach further. An attacker can create an account for themselves, assign a role to an account they control, leave one account out of the MFA policy, or add a trusted identity provider that can assert anyone's identity, as Abusing federation and account linking describes. Each looks like ordinary administration in the records, and each keeps working long after the attacker's original access is gone.
Making new footholds visible
Footholds are added through ordinary features, so preventing them means guarding the moments when those features are used. Adding a sign-in method, changing a recovery contact, approving an app and adding an application credential should each count a recent sign-in only if it used a phishing-resistant method, and otherwise ask for one at that moment. Riley's 09:14 sign-in used a password and a code, so at 09:20 the attacker would have met a passkey prompt that the relay could not answer.
Notifications let the owner notice what prevention missed. A message to Riley, through a channel that existed before the change, saying that a new authenticator was added or a new app approved, with a clear way to report "this was not me", turns the owner into a detector. The channel matters: a notice sent only to a recovery address the attacker just added reaches the attacker.
Monitoring watches for the patterns. On Day 2, Cedar's alert fired on exactly this kind of foothold: a sign-in from a hosting provider, then a new authenticator added minutes later from a network Riley had never used. Forwarding rules that send mail outside the organization, credentials added to applications and changes to trust configuration deserve the same attention, as Detecting identity attacks explains.
When one foothold turns up, it is rarely alone. Cleanup has to list the account's methods, recovery contacts, sessions, grants and rules, along with everything the account created or changed, then remove every unexpected item together with the password reset, as Containing and recovering describes. The following exercise asks what a reset on its own would do to each foothold.
What survives the reset?
Simulation. These records are made up, most of them from the fictional Cedar incident, and answering sends nothing. For each foothold, decide what a password reset on its own would do.