Skip to content

CONCEPT Cited by 1 source

Legacy shared account

Definition

A legacy shared account is a login on a third-party platform that sits outside the org's primary IdP-gated regime — typically because the platform doesn't support SSO federation at the org's tier, or because the account predates the org's SSO rollout, or because the platform was deprioritised at some point and the account fell below the security-hygiene threshold. The credentials are usually stored in a shared password manager (systems/1password|1Password, LastPass, Bitwarden) and accessed by multiple people (including sometimes external contractors).

The canonical properties:

  • No SSO. Cannot be placed behind the org's IdP.
  • Password + (maybe) TOTP. Phishable MFA at best.
  • Credentials in a shared vault. Multiple endpoints can pull them; each is a potential compromise vector.
  • Often has a contractor or agency with access for day-to- day posting / management.
  • Sits on a platform the org has deprioritised — "we might not be a long-term user of this platform" → the account gets demoted in mental priority → security investment stops.

Why they're dangerous

The entire org-level IdP regime becomes irrelevant because the account the attacker targets is the one that isn't behind it. Fly.io's 2025-10-08 postmortem is the canonical instance:

"Twitter, on the other hand. Yeah, so, about that. You may have heard that, a few years back, there were some goings-on involving Twitter. Many of us at Fly.io decamped for Mastodon, and later to Bluesky. There was a window of time in 2023-2024 where it looked as if Twitter might not be a long term thing for us at all. […] As a result, Twitter had been a sort of legacy shared account for us, with credentials managed in 1Password and shared with our zoomer contractor." (Source: sources/2025-10-08-flyio-kurt-got-got)

The structural claim: a deprioritised platform remains a credentialed attack surface. If the platform unexpectedly regains relevance (X/Twitter's post-2023 user retention exceeded many observers' expectations, Fly.io's included), the legacy- account security debt is now underwriting whatever brand exposure the account still has.

Fly.io's infrastructure was entirely unaffected — Google SSO + phishing-resistant MFA defended every internal system — but the Twitter account was exactly the one account outside that regime, and it was the one that got taken.

The failure pattern

  1. Org adopts SSO + phishing-resistant MFA for primary infra. Coverage is high within the IdP-federated surface.
  2. Some accounts can't be federated (platform doesn't support SSO at org's plan tier, or was acquired pre-SSO-era, or is a social account with no B2B SSO story, etc.).
  3. Those accounts go into a shared password manager as the pragmatic workaround.
  4. Some of those platforms get deprioritised. Security attention to the account drops below the threshold that would have caught the hygiene drift.
  5. Attacker phishes the shared-credential holder (often via the deprioritised platform itself — a phish about the platform being deprioritised is on-topic and plausible, which is the Fly.io flow: the Twitter-alert phish was about the Twitter account).
  6. Account taken over. Recovery is platform-gated (see concepts/account-takeover-ato).

Mitigations

  • Move onto phishing-resistant auth where the platform supports it. X/Twitter supports Passkeys; Fly.io's post- incident fix was "our Twitter access is Passkeys now."
  • Reduce the shared-vault sharing scope. One person with a passkey is strictly safer than five people sharing a password.
  • Inventory the platforms the org has accounts on. The legacy-account list is almost always incomplete; an audit is the only way to know.
  • Calibrate brand-damage tolerance per account. Decide in advance whether a legacy-social ATO is catastrophic or acceptable-for-the-brand-exposure — Fly.io's post implicitly claims their tolerance was "fine, we'll post a candid postmortem and move on," which is a valid policy choice but one that requires the incident to be scoped to brand-only blast radius (see patterns/incident-response-calibrated-to-blast-radius).
  • Autofill-only credential policy. If the vault's browser plugin won't autofill on a lookalike domain, forbid manual copy-paste as a matter of org policy (see patterns/password-manager-as-phishing-guardrail).

Seen in

  • Fly.io Kurt Got Got (2025-10-08) — canonical wiki instance. Twitter/X is the named legacy shared account that fell outside Fly.io's Google-SSO-gated infrastructure regime; the post is explicit about the platform deprioritisation (2023-2024 exit to Mastodon and Bluesky) preceding the security-hygiene drift that enabled the ATO (sources/2025-10-08-flyio-kurt-got-got).
Last updated · 517 distilled / 1,221 read