In 2019, a security researcher found an unauthenticated Kubernetes dashboard exposed on the internet belonging to Tesla. The dashboard provided full control over the Kubernetes cluster, including the ability to deploy containers, access secrets, and interact with internal services. Tesla's production applications were well-secured , their customer-facing APIs, their mobile app, their web application all had proper authentication, modern TLS, and reasonable security controls. But a single admin interface, exposed without authentication on a subdomain that nobody was actively monitoring, provided direct access to the infrastructure underneath all of it.
This pattern repeats with remarkable consistency across organizations of every size and industry. The customer-facing application is hardened. The admin interface , the one that has more privilege than any customer endpoint , is the weak link. Not because security teams do not know that admin panels need protection, but because the admin panel is often not in the security team's inventory in the first place.
Why These Surfaces Exist and Persist
The lifecycle of a forgotten admin panel typically follows a predictable sequence. A team needs an internal tool , a database management interface, a monitoring dashboard, a content management system, a debug console. They deploy it quickly, often on a subdomain or a non-standard port, with basic authentication or no authentication at all, because it is "internal" and "temporary." The tool works. It becomes load-bearing , people depend on it for operational tasks. The team that deployed it moves on to other projects, or the responsible engineer leaves the company. The tool continues running, silently exposed, with nobody responsible for its security or its eventual decommissioning.
The root cause is not carelessness. It is the absence of infrastructure lifecycle management as an explicit organizational function. Most organizations have processes for deploying new services but no corresponding processes for retiring them. There is no "service decommission review" that mirrors the "service launch review." There is no automated check that asks, once a quarter, "is this subdomain still needed? Who owns it? Is its authentication current?" The result is that the population of exposed admin surfaces grows monotonically. Every deployment adds to the surface area. Almost nothing removes from it.
Certificate Transparency (CT) logs have made this problem significantly worse from a defender's perspective. Every TLS certificate issued for a domain is logged in public CT logs, which means that every subdomain with HTTPS , including admin.example.com, staging-console.example.com, debug.internal.example.com , is publicly discoverable within hours of certificate issuance. Attackers do not need to brute-force subdomain names. They simply monitor CT logs (using tools like CertStream or services like crt.sh) for certificates matching target domains and immediately probe any new subdomain that appears.
The Economics of Attacker Discovery
The most common misconception about exposed admin panels is that "security through obscurity" provides meaningful protection. The argument goes: the admin panel is on a non-obvious subdomain or a non-standard port, so attackers will not find it.
This argument fails because discovery is cheap and automated. A comprehensive subdomain enumeration against a target domain , combining CT log queries, passive DNS databases, brute-force with common wordlists, and search engine indexing , takes minutes and costs nothing. Tools like subfinder, amass, and httpx chain these data sources into a pipeline that an attacker can run against thousands of targets per day.
Once an admin panel is discovered, the attacker's next question is what software it runs. Admin interfaces have distinctive fingerprints , page titles, CSS patterns, favicon hashes, response headers. Shodan and Censys already index these fingerprints across the entire internet, so in many cases the attacker does not even need to scan the target directly. They can search Shodan for org:"Target Company" http.title:"Grafana" and get results in seconds.
The authentication protecting discovered admin panels is typically one of: default credentials (admin/admin, admin/password), basic HTTP authentication with a shared password, a login form without rate limiting or MFA, or nothing at all. This is not a stereotype , it is an empirical observation from years of penetration testing. The admin panel was deployed as "internal tooling" and received the authentication treatment that implies: minimal.
The Subdomain Ownership Gap
In organizations with complex domain architectures, the problem is compounded by ambiguous ownership. Consider a typical enterprise DNS zone:
www.example.com, owned by the web team, secured by the application security teamapi.example.com, owned by the platform team, covered by API security standardsstaging.example.com, owned by... QA? DevOps? The team that existed two reorgs ago?analytics.example.com, owned by the data team, running a Grafana instance they deployed in 2022vendor-portal.example.com, set up during a vendor integration, still running after the vendor relationship endedold-crm.example.com, migrated from three years ago, DNS record never deleted
Each of these subdomains represents a distinct attack surface with its own authentication model, its own software stack, its own patch level, and its own responsible (or irresponsible) owner. Security coverage follows the organizational chart: the application security team covers the applications they know about. The subdomains that were deployed ad-hoc, by teams that no longer exist, for purposes that are no longer relevant, are in nobody's security scope.
The result is a Darwinian selection pressure: the admin panels that are well-known and well-owned get secured. The ones that persist undiscovered by the security team , the forgotten staging consoles, the orphaned vendor portals, the deprecated-but-still-running internal tools , are exactly the ones that have the weakest security posture and the highest probability of being compromised.
What Defenses Actually Work
The standard advice , "put admin panels behind a VPN" , is directionally correct but insufficient in practice. VPNs narrow the network exposure but introduce their own problems: VPN credentials can be phished or stolen, VPN clients on compromised endpoints provide access to the VPN network, and organizations often configure VPN access broadly ("all employees can reach the internal network") rather than narrowly ("only the database team can reach the database admin panel"). A VPN that gives every employee access to every admin panel is a broader access model than a properly-configured internet-facing application with strong per-user authentication.
The more effective approach combines several controls:
Continuous discovery. You cannot secure what you do not know about. Automated subdomain enumeration, port scanning, and service fingerprinting should run continuously against your own domains, with results feeding into an asset inventory that tracks ownership and security classification. When a new subdomain appears (detected via CT log monitoring or DNS zone tracking), it should trigger an ownership verification workflow before it is accessible from the internet. The gap between "deployed" and "inventoried" is the gap that attackers exploit.
Mandatory identity-first access. Every admin interface, without exception, should require authentication through the organization's identity provider with phishing-resistant MFA. Not basic auth. Not a shared password. Not local accounts on the admin application. SSO integration with the corporate IdP, with device posture checks where available. This is more work than setting a password in an .htpasswd file, but it provides centralized visibility (who accessed what, when), centralized revocation (disable the user's IdP account and all admin access revokes), and centralized policy enforcement (MFA, conditional access, session duration).
Explicit exposure policy. Every service should have an explicit classification: internet-facing, VPN-only, or internal-only. The default for admin interfaces should be "not internet-facing." Deploying an admin panel to the internet should require a documented exception approved by security, with a defined review date. This does not prevent all exposure, but it creates an organizational expectation that internet-facing admin panels are exceptions that require justification, not the default state.
Infrastructure-as-code enforcement. When infrastructure is deployed via Terraform, CloudFormation, or similar tools, security policies can be enforced at the infrastructure level. A policy that prevents creating public-facing load balancers or DNS records for services tagged as "internal" catches exposure at deployment time, before the service is accessible. This is more effective than discovering the exposure after the fact, but it requires that all infrastructure deployments go through the IaC pipeline , which is itself an organizational discipline that many teams circumvent for "quick" deployments.
The Uncomfortable Truth
The admin panel problem is fundamentally a governance problem disguised as a technical one. No amount of security tooling will compensate for the absence of infrastructure lifecycle management. If your organization deploys services without tracking ownership, without classifying exposure, without scheduled reviews, and without decommission processes, then the population of exposed, unmonitored, weakly-authenticated admin panels will grow until one of them is compromised.
The compromise, when it comes, will not be technically interesting. It will be an attacker who found a Grafana instance on a subdomain, logged in with default credentials, and pivoted to the underlying infrastructure. Or a phpMyAdmin installation on a staging server with a password that was set in 2021 and never rotated. Or a Jenkins instance that was supposed to be temporary and is now the longest-running service in the environment.
The fix is not a better firewall or a fancier WAF. The fix is someone in the organization being responsible for answering, continuously: "What admin interfaces do we have? Who owns them? Are they still needed? Are they properly secured?" Until that question has a clear answer and an accountable owner, the easiest path into most organizations will continue to be the admin panel that everyone forgot about.