Here's a distinction that gets lost constantly: "nobody has the link" is not the same thing as "this is private." A URL with no authentication behind it is public the moment it goes live, whether or not anyone's actually visited it yet. It's indexed by search engines eventually. It shows up in browser history, in a coworker's Slack DMs when they forward it along, in a security scanner's crawl of your company's known IP ranges if it's hosted somewhere predictable. Obscurity is not a security model, and every internal tool built without a login screen is running on obscurity alone.
This matters more than it used to because the tools without login screens aren't rare anymore. When only engineers could build internal software, most of it went through a deploy process that included auth almost by default, because the frameworks and platforms engineers reach for assume it. A tool built by someone outside engineering, fast, with a general-purpose AI assistant, skips straight past that assumption. Nobody told the builder to add a login screen. Adding one usually means standing up an auth provider, wiring session handling, and testing it, which is a lot to ask of someone who just wanted a dashboard.
What SSO actually buys you
Single sign-on isn't really about the login screen itself. It's about what that login screen is connected to.
When a tool sits behind your company's existing identity provider, access lives in one place: the same place that controls email, Slack, and every other system your company already gates. Offboard someone and their access to every SSO-gated tool disappears in the same motion, automatically, without anyone remembering to go find the one weird internal dashboard they had access to and revoke it separately. Add someone to the right group and they get access to everything that group is entitled to, without a separate invite for each tool.
Compare that to a tool with its own homegrown login, or worse, no login at all and just an unlisted URL. Offboarding means someone has to remember the tool exists, remember who had access, and manually revoke it — and in practice, on the tools nobody's tracking, that step gets skipped. The access just stays.
The excuse that doesn't hold up
"It's just an internal tool, it's not that sensitive" is the sentence right before the incident report. Even a tool with no obviously sensitive data attached is a foothold: a way to see who else has access, what your internal systems look like, what other tools exist. And plenty of "just an internal tool" projects end up reading from something that is sensitive, because that's usually the whole point of building it. Pulling real numbers into one place is what makes it useful in the first place.
A login screen tied to your existing SSO isn't a nice-to-have for internal tools. It's the baseline. If a platform for publishing these tools doesn't put one in front of every app by default, it's not actually solving the problem it claims to solve.