Credential paths

A credential edge is an attacker using a real identity's proof: the password, the key, the token, the session. Once they hold it, every control downstream sees a legitimate user. Grants, network policy, row-level security, all of it behaves correctly, because the warehouse is doing what the credential tells it to. That is why the credential door carries more paths than any other on Ironwood's graph, and why closing it changes the count more than any other single move.

It is also the cheapest door. MFA on human logins is a setting. Rotating a key is an afternoon if done in the right order, and a bad night if done in the wrong one. Neither requires a new product, and together they take Ironwood from nine paths to five before the storage, supply-chain and detection work has even started.

• Credential edge - a move on the graph where the attacker acquires a real identity's proof: reads a key from history, phishes a password, steals a session token. Downstream of it, they are the user.
• Second factor - proof that the person holding the password also holds a thing or a property: a device, a hardware key, a biometric. It closes the phishing edge because the password alone is no longer enough.
• Rotation - issuing a new credential and retiring the old one. The retiring is the security event; the issuing is the plumbing that makes retiring survivable.
• Expiry - the property that a credential stops working on a date whether or not anyone remembers it. A key with no expiry is a permanent door, and Ironwood's two-year-old key had none.
• Privilege edge - a move where a credential the attacker already holds reaches more than it should: the Friday admin grant. Not a credential problem; a grant problem, closed by least privilege.

A service key in a public repository's history is the most durable door on the graph. It does not phish anyone, it does not need luck, and it works from anywhere until somebody revokes it. Deleting the file from the repository does nothing: the commit that added it is still in history, and history is what a scanner reads. The only thing that closes the edge is the key no longer authenticating.

On Ironwood's ladder, rotation takes the count from 6 to 5, one path, even though two paths run through the ETL service key. The second is the CI runner, whose environment holds the key legitimately because it runs the pipeline. When the key is rotated the runner gets the new key, so a malicious package in the build still reaches a valid credential. Rotation closes the leaked copy; it cannot close the legitimate holder. That path is closed by pinning and verifying dependencies in session 4, and the distinction is exactly what the graph is for.

A phished password is a credential edge from the internet to a human login. On Ironwood's graph there are two: the analyst's and the admin's. Both are closed by the same control, because a second factor means the password alone no longer opens the door. The attacker still has the password; it has stopped being sufficient.

MFA removes three paths, not two, and the third is instructive. The phished analyst login reaches the warehouse directly, and it also reaches the admin login through the Friday grant. Closing the door at the internet closes both routes that start behind it. That is why MFA is the single highest-value edge removal on the graph: it is at the front of the chain, and everything behind it falls with it. 9 to 6.

What MFA does not do is touch the insider. The analyst's own login is their own; there is no phishing edge to close, and the Friday grant behind it remains. That is where the 6 comes from: the two paths that phishing opened and the one it opened through the grant are gone, and the insider's two are untouched.

One Friday a load failed, the analyst needed to fix it, and somebody granted them the admin role to unblock the afternoon. The load ran. The grant stayed, for two years, because nobody had the job of taking grants back. On the graph it is an edge from the analyst login to the admin login, and it is the reason the analyst's own login is worth two paths on Ironwood's ladder: one as themselves, one as admin.

Nothing tonight closes it. MFA closes the door in front of the analyst login for an outsider; it does nothing about what the login reaches once somebody legitimate is behind it. Rotation is about keys. The control that closes this edge is least privilege, meaning the analyst role reads what the analyst's work requires and the admin grant is gone, and that is the territory of the access-control course, where grants, role hierarchy and access review are taught properly. It is drawn as a gate here so the count is honest: after every other control on the ladder, the three paths that remain include this one, and least privilege takes the last three to one.

After a login succeeds, the warehouse or its SSO provider issues a session token, and every subsequent request presents the token rather than the password. A stolen token is therefore a credential edge that bypasses both the password and the second factor, because the login already happened. It is the reason MFA is a very large reduction and not a complete one.

• Short session lifetimes shrink the window in which a stolen token works. A token that lives for eight hours is a smaller door than one that lives for thirty days.
• Binding a session to the device or the network it started from makes a token useless when presented from anywhere else. Not every provider supports it; where it exists it is the strongest of these.
• Revoking sessions when a credential is rotated or a login is disabled. Changing a password does not end a session that is already open unless the sessions are ended too. Rotation and revocation are two separate actions.
• Where the token lives is a credential-lane inventory item: a browser, a notebook's cached connection, a laptop's config file. Session 1's credential lane includes these; the login history shows which are in use.

Ironwood's graph does not model token theft as a separate edge, because the controls above are properties of the login edge rather than a new door. On your own inventory, write the session lifetime next to each human login. A number you cannot find is a finding.

Five paths through the credential door at the start. Four closed tonight, one handed on with its name and its control written down.

Rotation is five steps and the order is the whole discipline. New key first. Store it in the secrets manager, so that the pipeline reads it from there and not from a file or an environment variable somebody will commit next year. Repoint the pipeline to the new key. Verify a full run succeeds, not a connection test, a run, because the connection test is how Ironwood's key got committed in the first place. Then, and only then, revoke the old key.

Through steps one to four the old key is still valid, which means nothing can break: the pipeline has two working keys and is using one of them. Step five is the only step that changes the security of the estate, and it is the one that is safe to take by the time you reach it, because everything that depends on the key has already been proven to work without it. Revoking first inverts this. The pipeline has zero working keys, the load fails, and the fix is done at 06:00 under pressure, which is when the old key gets put back.

A rotation is finished when the old key is refused, not when the new key works. The two are different facts and most rotation checklists verify only the first. Ironwood's key had been "rotated" once before the incident: a new key was issued and the pipeline moved to it, and the old key was left in place "for a few days, in case". The few days became eighteen months. The public repository still held a key that authenticated. The door had a new coat of paint.

Confirming the refusal is two checks. First, attempt to authenticate with the old key from a test host you control and expect a refusal; that is a test of your own credential against your own warehouse, and it is the only proof that revocation happened. Second, read the login history for the service account after the revocation timestamp and confirm that every successful authentication used the new key's fingerprint. A successful login on the old key after step five means step five did not happen, whatever the console said.

Then write the expiry date of the new key into the inventory file, because a key with no expiry is the same door two years from now. The inventory's credential lane carries an expiry column for exactly this reason.

MFA is a human control. It works because a person is present to hold a device and approve a prompt. A service account runs at 02:00 with nobody present, so a second factor is not available to it, and a password on a service account is a credential that can be phished from whoever knows it and can be committed to a repository by whoever uses it. The pattern that replaces MFA for a service account has three parts, and it is a pattern rather than a product.

• Key-pair or federated authentication instead of a password. A private key that never leaves the secrets manager, or a short-lived token issued by the platform's own identity to the workload, so there is no long-lived secret to leak. Either way there is nothing to type and therefore nothing to phish.
• Network allowlisting on the service account. The key authenticates only from the addresses where the pipeline runs. A leaked key that works from anywhere is Ironwood's baseline; a leaked key that works from three addresses is a much smaller door. This is the one thing the perimeter-only over-correction on the ladder gets right, and on a service account it is correct rather than an over-correction.
• Expiry and rotation on a schedule, written into the inventory, so that the key that leaks next year has already stopped working by the time anyone reads it out of history.

None of this replaces the query log. A service account with a key pair, an allowlist and an expiry date still reads the customers table every night, and detection in session 5 is how you would notice it reading eleven thousand more rows than usual.

A second factor that a person approves is a control that depends on the person reading the prompt. Send enough prompts at the wrong hour and some fraction of people approve one to make it stop. This is not a failure of the person; it is the predictable behaviour of a control that turned a security decision into an interruption. It is also the reason MFA on Ironwood's ladder is a reduction from 9 to 6 and not a claim that phishing is solved.

• Number matching, where the prompt shows a code that must be typed from the login screen, means an approval requires the person to be at the screen that started it. It converts "tap to approve" into "prove you are the one logging in".
• Phishing-resistant factors, hardware keys and platform authenticators bound to the site's origin, do not produce a prompt an attacker can trigger from elsewhere. They are the strongest option and the one to use for admin logins first.
• Fewer prompts: a session lifetime that means people authenticate a few times a week rather than a dozen times a day keeps the prompt meaningful. A control people meet forty times a day is a control they stop reading.
• A prompt nobody sent is an alert. When a person reports an unexpected prompt, that is the phished-password edge being attempted in real time, and it is the cheapest detection on the whole estate. Make reporting it one tap, and make sure somebody reads the reports.

The professional norm is to state the limit plainly: MFA closes the phishing edge for the majority of attempts and raises the cost of the rest. It is a very large reduction, it is not zero, and the rest of the ladder exists because it is not zero.