Identity & Access Control
Default password
A default password is a preconfigured password supplied with a device, application, or account before it is changed.
In plain terms
A default password is the preset password a device or app comes with before you change it. Leaving it as-is is a classic, easily-exploited mistake, since these defaults are public knowledge.
Manufacturers and developers routinely bundle a known, shared password with their products to allow initial setup - a default password that becomes a serious vulnerability the moment the device or service goes live without being changed. It may be printed in documentation, reused across a product line, generated from a predictable pattern, or bundled into deployment images.
Default passwords are dangerous because attackers can learn them easily. Product manuals, leaked setup guides, internet scans, botnets, and credential lists often contain default credentials. If an organization leaves defaults unchanged, attackers may gain access without exploiting a software vulnerability.
Default passwords are closely related to default credentials. A default credential may include a username, password, API key, token, certificate, or shared secret. The password is only one part of the broader default-access problem.
NIST SP 800-63B addresses memorized secrets and verifier behavior, while NIST SP 800-53 account management and identification controls support changing or disabling default authenticators. Many security baselines also require default passwords to be changed before production use.
Common targets include routers, cameras, printers, firewalls, industrial devices, database consoles, web applications, cloud images, development tools, and vendor support accounts. Internet-connected devices with unchanged defaults are routinely abused for botnets and unauthorized access.
The safest product design avoids shared defaults. A device or application should require a unique password at first use, generate device-specific credentials, or support secure enrollment. Shared factory passwords create risk before the customer even configures the system.
Operational onboarding should include default credential removal. Commissioning checklists, configuration baselines, vulnerability scans, and asset acceptance tests should confirm that default passwords are changed, disabled, or replaced with managed authentication before the asset is connected to sensitive networks.
Common failure modes include changing the main administrator password but leaving vendor support accounts, SNMP communities, database defaults, local console accounts, API keys, or recovery accounts unchanged. Attackers often try these overlooked paths.
Password managers and vaults help when unique local credentials are necessary. Storing a unique device password in an approved vault is better than reusing one “temporary” password across a fleet. Rotation should be possible when staff or vendors change.
Scanning can identify exposed defaults, but it must be careful. Aggressive credential testing can lock accounts, disrupt fragile devices, or violate acceptable use rules. Authenticated configuration review and safe scanning profiles are often better for production.
Default passwords also matter in development. Test credentials, sample configuration, container images, and demo accounts sometimes reach production. CI/CD checks and secret scanning can catch hardcoded defaults before deployment.
Incident response should check for default credentials when investigating unauthorized access. If attackers used a default password, responders should identify every asset of the same type, rotate credentials, review logs, and determine whether the same vendor account exists elsewhere.
The explicit failure mode is assuming default passwords are only a beginner mistake. Large enterprises still inherit default credentials through acquisitions, emergency deployments, lab systems, unmanaged appliances, and vendor-managed environments.
Metrics can track assets with default credential findings, time to remediate, product classes with repeated issues, and exceptions for vendor support. Persistent default password findings usually indicate weak asset onboarding.
In practice, a default password is known or guessable trust. It should be removed before production, monitored during asset lifecycle, and treated as a serious authentication weakness when found. The remediation should include more than changing one password: identify the product family, search for similar assets, review vendor support accounts, check logs for use of the default credential, and update build or onboarding procedures so the same condition does not return. Default passwords are often symptoms of weak asset commissioning. A mature process proves that new devices, images, containers, applications, and appliances cannot enter production with shared or predictable credentials still active. Procurement and vendor security reviews should also ask whether products force unique credentials at first use and how emergency recovery accounts are protected. Internet exposure makes default passwords urgent. A device with an unchanged credential on a private lab network is still a weakness, but the same device exposed through port forwarding, VPN access, or a misconfigured cloud security group can be compromised quickly. Asset exposure should drive remediation priority. Finding one default password should trigger a class search, because products are often deployed from the same image, checklist, vendor process, or emergency build procedure. One finding usually implies others.