Yes, internal tools need authentication and authorization. "Internal" describes where a tool is hosted, not who can reach it or what it can do. A portal, dashboard or CLI that holds tokens and can change production is a target, and frameworks often ship open by default, so the control has to be added on purpose.
Myth 1: "It is behind the VPN, so it is fine"
Fact: a network boundary is one layer. Anyone on that network, any compromised laptop and any malicious extension or script running as a developer can reach it. The Backstage documentation is a good example of the default posture: by default its endpoints are not protected and all actions are available to anyone, and the frontend bundle is not protected from external access without extra setup. That is documented behavior for a framework, not a flaw, but it means "we installed it" is not the same as "we secured it".
Myth 2: "Only developers use it, and we trust developers"
Fact: you may trust the person and still not trust everything running as them. Developer machines run extensions, plugins and scripts. VS Code's documentation says extensions run with the same permissions as the editor. The kubectl documentation says third-party plugins are arbitrary programs running on your machine. If an internal tool authenticates only by "request came from a developer's session", compromise of any of those tools compromises the internal one.
Myth 3: "It has no sensitive data"
Fact: look at what it holds and what it can do. The question is not only what it stores. Internal tools often carry credentials for source control, CI, cloud accounts and ticketing, and they can trigger actions such as creating repositories, running pipelines or changing configuration. A token with write access is sensitive even if the tool's own database looks boring.
Myth 4: "Nobody outside knows it exists"
Fact: obscurity is not a control. Hostnames leak through certificates, logs, emails and screenshots. Assume someone will find it, then ask what they could do.
What to do instead
| Question | Good answer |
|---|---|
| Who can sign in? | Staff through your identity provider, with MFA |
| What can each user do? | Defined by roles and enforced server side, not just hidden buttons |
| What does the tool hold? | A short list of credentials, each narrowly scoped and owned |
| What can it change? | Documented actions, each logged |
| How is it updated? | From a reviewed source, with a known owner |
A one page inventory of internal tools with an owner, a data classification, an authentication method and a last review date will catch most of the gaps. Start with the tools that can write: deployment, access management, release and data tools.
A fast way to find the worst one
Ask each team for the one internal tool they would be most worried about if it were public. Then test that tool from a clean browser and a command line with no credentials. Anything that answers is today's priority.
Where Safeguard fits
Safeguard's asset discovery helps you find what is running, and its policies and gates help you control changes to it. The free scan at gold.safeguard.sh/scan is a quick way to look at a tool's dependencies.
Quick check
Is a VPN enough authentication for an internal tool?
No. It limits who can reach the tool but does not identify users or limit what each can do, and compromised devices on the network still reach it.
What is the first internal tool to review?
The one that can write to production or holds the broadest credentials, usually deployment, access or release tooling.
Sources
- Permissions overview, Backstage documentation
- Authentication in Backstage
- Extension runtime security, Visual Studio Code documentation
- Installing kubectl plugins, Kubernetes documentation
Last reviewed: 19 October 2026.
