If our code host goes down, what else breaks?

The question

The client's engineering team stores code elsewhere. Their first instinct was that the outage was somebody else's problem.

What we told them

Check what else in the company logs in with a "Sign in with GitHub" button first — that was the real exposure, not the code hosting itself. When GitHub went down for nearly eight hours, it took a chunk of enterprise SSO, SAML, OIDC, and SCIM logins down with it, because GitHub isn't just a code host to a lot of organizations. It's also the identity provider quietly sitting behind other tools people log into every day. Teams that had never pushed a line of code to GitHub still found themselves locked out of software, because some other vendor decided GitHub login was the easiest way to onboard users.

This isn't an argument against single sign-on. One login across your tools is usually the better security posture — fewer passwords floating around, easier to revoke access when someone leaves. The problem is treating it as risk-free just because it's convenient. Every "Sign in with X" button is a dependency on X's uptime, and most companies have no idea how many of those dependencies they've quietly accumulated. We walked the client through two things:

• Map your identity dependencies. Go through your tool list and note which ones authenticate through which provider — GitHub, Google, Microsoft, Okta, whatever it is. Most businesses have never written this down.
• Keep a break-glass path. At least one way into your most critical systems that doesn't route through the same identity provider as everything else, for the day that provider has a bad afternoon.