Default Credentials Are Still the Biggest Risk

Why do default credentials persist?

Default credentials should be a solved problem. Every security framework recommends changing them. Every vendor warns against leaving them in place. Yet they remain the initial access vector in breach after breach.

The reasons are structural, not technical:

Volume. A mid-size organisation runs hundreds of services, appliances, and devices - each with its own management interface and default credentials. Routers, switches, printers, IP cameras, CI/CD tools, monitoring dashboards, database consoles, IoT sensors. The sheer number of credentials to change creates gaps.

Urgency. When a service needs to be deployed quickly - to fix an outage, meet a deadline, or unblock a team - “change the default password” becomes a step that gets deferred. Production urgency consistently overrides security hygiene.

Invisibility. Security teams often don’t know a service exists, let alone that it’s using default credentials. Shadow IT, contractor-deployed tools, and embedded device firmware create management interfaces that never appear in a credential rotation policy.

Embedded defaults. Some devices use hardcoded credentials that cannot be changed - they are compiled into firmware. Others use default credentials for service accounts that perform background operations, making them harder to discover and change.

How are default credentials exploited at scale?

Botnets continuously scan the internet and attempt default credential combinations against every login page they find. This is not targeted - it’s opportunistic and industrial-scale.

The Mirai botnet, which recruited hundreds of thousands of IoT devices into a DDoS network, spread primarily by trying 62 default username/password combinations against Telnet services. The attack succeeded because enough devices on the internet were still using factory credentials.

This pattern hasn’t changed. Modern botnets and initial access brokers maintain credential lists for thousands of products and test them against every exposed management interface. If your panel is reachable and uses default credentials, it will be compromised - the only variable is when.

Where do default credentials hide?

The obvious defaults - admin panels with admin/admin - are easy to identify. The dangerous defaults hide in less obvious places:

Network devices. Routers, switches, firewalls, and access points often ship with vendor-specific defaults (Cisco/cisco, admin/1234, etc.). Firmware updates don’t reset changed passwords, but they don’t flag unchanged ones either.

Monitoring and observability tools. Grafana, Prometheus, Kibana, and similar tools are often deployed by operations teams focused on getting dashboards running, not on authentication configuration. Grafana’s default admin/admin is one of the most commonly found exposed credentials on the internet.

Database management interfaces. phpMyAdmin inherits the database credentials, but the database itself may have default users. MongoDB historically shipped with no authentication enabled by default - not even a default password, just no authentication at all.

Appliances and embedded systems. Print servers, UPS management cards (iLO, iDRAC, IPMI), building management systems, and industrial control panels use firmware-level credentials that are often undocumented or require physical access to change.

Service accounts and API keys. Default API tokens, webhook secrets, and inter-service credentials are often set to placeholder values during development and never rotated for production.

How do you eliminate default credentials?

A systematic approach to default credential elimination:

1. Inventory all management interfaces. You cannot change credentials on panels you don’t know about. Continuous attack surface scanning is the foundation.

2. Establish a credential policy. Every management interface must have unique credentials set before it is exposed to any network - even internal ones. Make this a deployment checklist requirement.

3. Use a secrets manager. Store service credentials in a secrets manager (HashiCorp Vault, AWS Secrets Manager, 1Password for Teams). This makes credential rotation manageable at scale and creates an audit trail.

4. Automate detection. Include default credential checks in your CI/CD pipeline for infrastructure-as-code deployments. Flag Terraform, Ansible, and Docker configurations that reference known default values.

5. Prioritise by exposure. An internal-only panel with default credentials is a risk. An internet-facing panel with default credentials is an emergency. Triage based on network exposure.

6. Address embedded defaults. For devices with hardcoded credentials, compensating controls (network segmentation, VPN-only access, monitoring) are the only option. Track these devices separately and replace them when the vendor offers firmware with configurable credentials.

Why are default credentials a supply chain problem?

Default credentials are a supply chain problem. Vendors ship insecure defaults because it simplifies installation. Resellers and integrators deploy products with defaults because it reduces support calls. Customers inherit the risk.

Until vendor practices change - and regulatory pressure from frameworks like the EU Cyber Resilience Act is pushing in this direction - the burden falls on organisations to discover and remediate their own default credentials. The first step is visibility: knowing where your management interfaces are and which ones are exposed.