Default Credentials
Default credentials are the factory-set usernames and passwords (admin/admin, root/root, vendor-specific pairs) that ship with a device or application and are never changed, letting anyone who knows the published default log in with full access. Because the defaults are documented publicly and reused across every unit of a product, an internet-reachable device with its default left in place is effectively unauthenticated.
A camera, router, or admin panel that still answers to its out-of-the-box password is not a low-priority hygiene item; it is an open door that an attacker reaches by typing two words. The credential is not secret, it is printed in the manual and indexed by search engines, so the only thing standing between an adversary and full administrative control is whether someone remembered to change it. On an external attack surface, that single oversight collapses every other control behind it.
Reviewed by Ameya Lambat
Security Research Contributor, Legba
Reviewed 2026-05-28 · Updated 2026-05-28
What it is
Default credentials are the authentication values a vendor pre-configures so a product works immediately after installation. They include classic combinations such as admin/admin, root/root, admin/password, and blank passwords, as well as device-specific pairs documented in firmware and user guides. Manufacturers ship these to simplify provisioning, expecting operators to change them during setup. When that step is skipped, every unit of that product shares the same logically public secret. The weakness spans CWE-1392 (Use of Default Credentials), CWE-798 (Use of Hard-coded Credentials) when the value cannot be changed at all, and CWE-1391 (Use of Weak Credentials). It applies to consumer and enterprise gear alike, from a home router's web UI to an enterprise database superuser account or a server's baseboard management controller.
An external device left on its default login is a one-step compromise: there is no brute force to detect, no exploit chain to assemble, just a known password applied to a known account. CISA's Secure by Design Alert on default passwords states that years of evidence show relying on customers to change passwords is insufficient, and that threat actors routinely look up a default password on the public internet and test it against internet-exposed devices. The stakes are concrete. The Mirai botnet weaponized exactly this weakness, scanning the internet over Telnet and trying roughly 60 hard-coded default credential pairs to enslave hundreds of thousands of cameras and routers, then launched record-setting DDoS attacks that knocked major services offline. For your organization the loss is direct: an attacker who logs into a default admin account can pivot into the internal network, exfiltrate or destroy data, hold systems for ransom, or conscript the device into a botnet that gets your IP ranges blocklisted. What you stand to lose is not a setting, it is control of the asset and everything reachable from it.
At a glance
How attackers find and exploit it
- Enumerate internet-facing hosts and services using mass scanners and search engines (Shodan, Censys, masscan), filtering for management ports and product banners that reveal a specific make and model.
- Fingerprint the exact device or application from HTTP titles, login page markup, SSH/Telnet banners, favicon hashes, and TLS certificate fields to determine which vendor defaults apply.
- Look up the published default username and password for that product in vendor manuals, support pages, and curated default-credential databases such as the SecLists and DefaultCreds collections.
- Attempt the default pair against the exposed login, often automated across many hosts at once because the same credential works on every unconfigured unit of the product.
- On success, authenticate as administrator, then change configuration, add accounts, dump credential stores, or upload firmware/web shells to establish persistence.
- Pivot from the compromised device into the internal network or chain the access into a larger campaign, for example loading DDoS bot code as Mirai did or staging ransomware deployment.
How to detect it on your surface
- Inventory every internet-reachable asset that presents a login: routers, firewalls, cameras, DVRs, printers, IPMI/BMC interfaces, databases, and web admin consoles.
- Cross-reference each asset's make, model, and software version against a maintained list of vendor default credentials for that product family.
- Attempt an authenticated login with the known default(s) in an authorized, controlled test against each identified asset, recording which accept the default.
- Check for default accounts that remain enabled even when a new admin password exists, such as guest, service, or vendor backdoor accounts that ship active.
- Review provisioning and onboarding records to confirm a forced password change actually occurred for each device, rather than assuming it did.
Detection signals
- Login succeeds with a documented factory pair (e.g., admin/admin, root/root, admin/password) or with an empty password.
- HTTP login pages, SSH/Telnet banners, or HTTP titles that identify a specific vendor and model whose defaults are publicly known.
- Telnet (port 23) open and reachable on a consumer-grade device, frequently indicating unmanaged firmware that still trusts hard-coded credentials.
- Web UI that loads a setup wizard, a 'change your password' prompt, or a 'default password in use' warning banner, signalling provisioning was never completed.
- Management interfaces (IPMI/BMC, switch web UI, database admin port) exposed externally where vendor superuser accounts are enabled by default.
Validate before you report
- Confirm the asset is genuinely owned by your organization and in scope before any credential test, then perform the login attempt from an authorized source.
- Authenticate with the matched default credential and capture evidence of the access level granted (admin dashboard screenshot, account list, version string) rather than just a 200 response.
- Verify the session yields real privilege, for example the ability to read configuration or list users, distinguishing a working default from a decoy or read-only landing page.
- Record the exact credential pair, the endpoint, timestamp, and source, so the finding is reproducible and the remediation owner can confirm the fix.
- Re-test after remediation to prove the default no longer authenticates and that no shadow default account remains enabled.
What looks like this but isn't
- A login page that displays a default-credentials hint but rejects them indicates the operator already rotated the password; this is hardened, not vulnerable.
- Honeypots and deception assets are designed to accept default logins to lure attackers; confirm the host is a real production asset before flagging.
- Some appliances show a generic 'admin' welcome page pre-authentication that does not grant privilege; verify that the default actually authenticates an administrative session, not just renders a public page.
Remediation
- Immediately change every default credential to a unique, strong, randomly generated value and store it in a secrets manager or password vault.
- Disable or delete unused default and vendor accounts entirely rather than only changing their passwords, removing dormant backdoors.
- Restrict management interfaces so they are not reachable from the public internet; place them behind a VPN, bastion host, or IP allowlist.
- Enforce a mandatory password change at first login and, where supported, phishing-resistant multifactor authentication on all administrative access.
- When procuring equipment, prefer vendors that follow CISA Secure by Design practices such as unique per-device setup passwords or time-limited setup credentials.
- Establish a recurring authenticated scan that re-tests for default and weak credentials across the asset inventory and feeds results into ticketing.
Operational checklist
- Maintain a live inventory of all externally reachable login surfaces with make, model, and version recorded.
- Run scheduled default- and weak-credential checks against that inventory and alert on any new positive.
- Require, as a documented build/onboarding gate, that every device has its defaults rotated before it goes live.
- Keep management planes off the public internet by default and review exceptions quarterly.
- Enforce MFA and least-privilege on all admin accounts, and rotate shared service credentials on a fixed schedule.
- Track vendor security advisories for hard-coded or undocumented default accounts and patch or mitigate promptly.
What to do next
A default credential left in place is the cheapest compromise an attacker can make and one of the most expensive for you to recover from, because it hands over administrative control without tripping a single alarm. The fix is equally direct: find the asset, prove the default still works, and rotate or remove it today. Start by listing every internet-facing login you own and testing the published defaults against each one this week, before someone else does.
Methodology
Each finding-type guide is built from Legba Recon's real detection and validation logic, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.
FAQs.
References.
- 01Secure by Design Alert: How Manufacturers Can Protect Customers by Eliminating Default PasswordsCybersecurity and Infrastructure Security Agency (CISA)
- 02
- 03
- 04Mirai (malware)Wikipedia
