Many scanners try well-known default logins against admin panels and devices, and that finds real problems. They rarely find defaults you created yourself, such as a shared starter password for new accounts. Those need configuration review, code review or a grey-box test.
What counts as a default credential
The OWASP Web Security Testing Guide separates three cases.
- Vendor defaults: built-in administrative accounts with static or guessable passwords, common on applications and hardware.
- Organization defaults: passwords staff set when creating accounts, such as one shared password, one based on the company name, or a pattern like a weekday plus digits.
- Application generated defaults: passwords the app creates for new users that turn out to be predictable.
The guide lists the weaknesses behind generated passwords: a single static string shared across accounts, a hash of account details such as md5 of the username, a time-based algorithm, or a weak pseudo-random number generator.
What a scanner can do
For the first case, a tool can identify the software, then try a short list of known default pairs, or common choices such as admin, password or a blank value. This works well against exposed admin consoles, network devices and software left at its install settings. It is a cheap check and worth running on anything that faces the internet.
The testing guide suggests the same approach by hand: identify the software, search for its default password, read vendor documentation, and try common options if nothing is documented. It also mentions checking physical hardware for stickers, which no scanner will do for you.
What it cannot do from outside
- Organization defaults. The guide notes that these are difficult to identify in a black box test unless guessing or brute forcing works, and easy to identify when you have inside access. A scanner cannot know your onboarding habits.
- Generated defaults. To find them, someone has to create several accounts at the same time and compare the passwords. A scanner does not do that unless built for it.
- Accounts behind other doors. A default password on a database, message broker or internal tool that the scanner cannot reach goes unchecked.
- Lockout side effects. Testing many guesses against a live login may trigger lockouts, so tools are often limited on purpose.
A practical review
| Question | How to answer it |
|---|---|
| Which software here ships with a built-in admin account? | Inventory it, read the vendor documentation |
| Were default passwords changed at install? | Review the configuration or try the login in a test copy |
| How do we set first passwords for new users? | Check the onboarding process, prefer one-time links over shared passwords |
| Does the app generate passwords? | Create several accounts and compare the results |
| Do any exposed consoles use a default? | Run an authenticated or credentialed check on internet-facing hosts |
Forcing a password change on first login and removing unused accounts close most of these gaps. Our secure password reset flow checklist covers the one-time link approach.
Where this sits in the standards
CWE-1392 covers use of default credentials as a weakness class. If you track findings by weakness type, tag these separately from guessable user passwords, since the fix is different: configuration and process, not input handling.
Quick check
If my scanner reports no default logins, am I fine?
Only for the products it knows about and can reach. Your own onboarding passwords and generated passwords need a separate review.
Is a shared starter password ever acceptable?
OWASP lists it as a weakness. Prefer unique one-time credentials and a forced change at first login.
Safeguard offers a free scan at gold.safeguard.sh/scan for your dependencies, and its asset discovery helps you find software you forgot you were running.
Sources
Last reviewed: 19 October 2026.
