Cybersecurity glossary
What are Default Credentials?
Learn what default credentials are, why unchanged vendor passwords enable takeover of apps and appliances, how they relate to authentication failures, and how to force unique secrets at deploy time.
Definition
Default Credentials are factory-set or documentation-published usernames and passwords (or API tokens) that remain active after deployment—allowing anyone who knows or looks up the vendor defaults to authenticate as an administrator or service account.
Why default credentials matter
Scanners do not need a zero-day when admin / admin still opens the console. Default Credentials are unchanged vendor logins—documented, identical across fleets, and first on every botnet wordlist. They are a security misconfiguration that collapses into authentication failures: the secret was never a secret.
Attackers often combine forced browsing to find /admin with a default pair. Distinct from parameter tampering or crypto gaps in sensitive data exposure, the flaw is simply that the out-of-box authenticator still works.
How default credential attacks work
Identify the product
Banners, TLS certs, or UI fingerprints reveal vendor and version.
Look up factory logins
Manuals, GitHub, and default-password databases supply candidate pairs.
Hit the management surface
Admin UI, SSH, DB port, or API accepts the documented account.
Take over the system
Attacker changes configs, plants persistence, or pivots into the network.
Where defaults persist
Appliances and IoT
Cameras, routers, and printers shipped with printed stickers still active.
Data stores and brokers
Redis, MongoDB, message queues installed with empty or known passwords.
Admin and debug UIs
Framework consoles and actuators protected only by vendor defaults.
Golden images
AMI/VM templates that bake the same password into every instance.
Prevention that works
| Control | Notes |
|---|---|
| Forced first-login change | Block useful function until a unique password is set |
| Unique provisioned secrets | Generate per-instance passwords into a vault at deploy |
| Disable unused accounts | Remove guest, demo, and documentation sample users |
| Default-credential scanning | CI and continuous external scans for known pairs |
| No hardcoded service passwords | Prefer workload identity or short-lived tokens over baked secrets |
| Inventory management planes | Every admin URL must have an owner and rotation policy |
- Inventory all admin UIs, DBs, brokers, and appliances in each environment.
- Change or disable every vendor default account before go-live.
- Automate unique secret injection at provision time; forbid shared lab passwords in prod.
- Scan continuously for known default pairs on exposed management ports.
- Require first-boot password change on appliances you ship or buy.
- Review golden images so they never contain production-usable defaults.
- Treat successful default login as critical [authentication failures](/glossary/authentication-failures).
- After any exposure window, rotate secrets and audit for persistence.
The practical takeaway
Default credentials are vendor logins left unchanged. Force unique secrets at deploy, disable unused factory accounts, and scan for known pairs—especially on admin panels found via forced browsing.
If a product still accepts the password from its quick-start guide, it is already compromised for anyone who can reach the login page.
Related security terms
Authentication Failures
Broader identity weaknesses; defaults are a high-impact subset.
Security Misconfiguration
Deploying with out-of-box accounts is a classic misconfiguration.
Forced Browsing
Finding admin panels that still accept vendor logins.
Debug Endpoint Exposure
Management interfaces often ship with documented default passwords.
Frequently asked questions
What are default credentials in simple terms?
The username and password the vendor printed in the manual—admin/admin, root/pass, device serial as password—still work on the live system because nobody changed them.
Why are default credentials so dangerous?
Attackers and worms automate well-known pairs against admin panels, databases, and IoT. One unchanged login often yields full control without exploiting a code bug.
How do they differ from weak user-chosen passwords?
Weak passwords are unique-but-guessable per account. Defaults are identical across many deployments and published in docs, firmware dumps, and scanner wordlists.
Where do teams still find them?
Appliance UIs, embedded devices, CI dashboards, message brokers, databases, [debug endpoints](/glossary/debug-endpoint-exposure), and cloud images cloned from vendor templates.
How do you prevent default credentials?
Force password change on first boot, generate unique secrets at provision time, disable unused default accounts, and fail deploy pipelines if known defaults remain.
Is renaming the admin user enough?
Helpful but insufficient if the password is still the documented default. Change the secret, preferably to a randomly generated high-entropy value in a vault.
How does this relate to authentication failures?
OWASP groups unchanged defaults under identification and [authentication failures](/glossary/authentication-failures)—the authenticator is predictable rather than privately held.
References
Explore authoritative guidance and frameworks related to default credentials.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.