Skip to main content
Commerce Security Authority
Category: Vulnerability and Software Security

Default Accounts and Passwords

Also known as: Default Credentials, Vendor-Supplied Defaults, Factory Default Passwords
Simply put

Default accounts and passwords are the pre-set login credentials that vendors ship with hardware devices, software, and applications for initial setup and testing. Because these defaults are widely documented and often published in public databases, attackers frequently try them as one of the easiest ways to gain unauthorized access to a system. Many vendors recommend changing these credentials, and replacing them helps reduce the risk of compromise.

Formal definition

Default accounts and passwords are pre-configured, vendor-supplied credentials intended for initial testing, installation, and configuration operations. Because such credentials are commonly enumerated in publicly maintained repositories spanning many vendors and devices, they present a well-known attack surface: trying default accounts and passwords is among the simplest techniques for penetrating a system. Hardening practice calls for changing or disabling vendor-supplied defaults—including default account names, passwords, and other security parameters—on network devices, applications, and endpoints before or immediately upon deployment. In a PCI DSS context, management of vendor-supplied defaults is addressed by the standard's system configuration and hardening requirements; because requirement numbering and wording differ between PCI DSS versions, practitioners should confirm the applicable requirement against the current published standard rather than assuming a fixed reference. This term is distinct from broader authentication controls such as multi-factor authentication and password strength policies, which address related but separate risks.

Why it matters

Default accounts and passwords represent one of the most well-known and easily exploited weaknesses in any system. Because vendors ship devices, applications, and network equipment with pre-set credentials for initial setup, and because those credentials are widely documented in publicly maintained repositories, an attacker who knows the make and model of a target system can often look up the factory defaults with little effort. As one industry auditor's account notes, trying default accounts and passwords is among the easiest ways to attempt access to a computer system, which is precisely why hardening guidance consistently emphasizes changing or disabling them.

The scale of the exposure is illustrated by public repositories that catalog default credentials across hundreds of vendors and thousands of individual passwords spanning network devices, applications, and endpoints. Government advisories, including guidance published by CISA, have highlighted the risks associated with leaving default passwords in place, noting that these credentials are intended only for initial testing, installation, and configuration and that many vendors recommend changing them. When defaults remain unchanged after deployment, they leave a standing, well-documented entry point that requires no sophisticated technique to abuse.

Addressing vendor-supplied defaults is a foundational element of system configuration and hardening. Removing or changing them helps reduce the risk of unauthorized access, but it is not a complete authentication strategy on its own; it works alongside other controls such as strong password policies and multi-factor authentication. Practitioners should treat changing defaults as a baseline step rather than a comprehensive safeguard.

Who it's relevant to

Security Engineers and System Administrators
Those responsible for provisioning and hardening systems must identify and change or disable all vendor-supplied default accounts, passwords, and other security parameters before or immediately upon deployment. This applies to network devices, applications, and endpoints, and should be verified as part of build standards and configuration baselines.
Compliance Officers and PCI DSS Assessors
Managing vendor-supplied defaults is addressed within PCI DSS system configuration and hardening requirements. Because numbering and wording vary between versions, assessors should confirm the applicable requirement against the current published standard and validate that defaults have been removed or changed across in-scope systems rather than assuming a fixed reference.
Merchant Risk and Acquirer Teams
Unchanged default credentials on merchant-facing devices and systems represent a foundational configuration weakness that can contribute to compromise. Teams evaluating merchant security posture may treat the handling of vendor-supplied defaults as a baseline indicator of broader hardening discipline.
Vendors and Product Integrators
Organizations that ship hardware or software with pre-set credentials should provide clear guidance recommending that customers change defaults, since these credentials are intended only for initial testing, installation, and configuration and are frequently published in public repositories once a product is released.

Inside Default Accounts and Passwords

Vendor-Supplied Default Accounts
Predefined user or administrative accounts shipped with hardware, operating systems, databases, applications, and network devices. These accounts are widely documented and often known publicly, making them a common target for attackers seeking initial access.
Default Passwords
Preset credentials associated with default accounts. Because they are consistent across installations of the same product and frequently published in vendor documentation, they must be changed before or upon deployment.
Other Default Security Parameters
Settings beyond accounts and passwords, such as default SNMP community strings, default encryption keys, default configuration flags, and unnecessary enabled services that can weaken the security posture of a system if left unaltered.
System Hardening Baselines
Documented configuration standards that address the removal or disabling of default accounts, changing of default credentials, and elimination of unnecessary default functionality across in-scope system components.
Scope of Applicability
Default accounts and passwords are addressed across many types of components in the cardholder data environment, including operating systems, security software, applications, point-of-sale terminals, payment applications, and network infrastructure.

Common questions

Answers to the questions practitioners most commonly ask about Default Accounts and Passwords.

If we change a vendor-supplied default password, does that mean the default account itself is now safe to keep?
Not necessarily. Changing the password addresses only one aspect of the risk. Default accounts are widely documented and predictable, so they remain attractive targets even with a strong password. PCI DSS guidance generally calls for changing vendor-supplied defaults before installing a system on the network, and for removing or disabling default and unnecessary accounts where they are not needed. Where a default account cannot be removed because it is required by the system, it should be secured according to the vendor's hardening guidance and the applicable requirement in the current published standard. Retaining an unused default account solely because its password was changed still leaves an avoidable exposure, so confirm the specific expectations against the current version of PCI DSS rather than assuming a password change alone satisfies the control.
Does this control only apply to passwords, or does it cover other default settings too?
It covers more than passwords. The intent extends to vendor-supplied defaults broadly, which can include default accounts, default SNMP community strings, default encryption keys or certificates, default wireless settings, sample or demo content, and other preconfigured values shipped by a vendor. Treating this as a password-only exercise can leave other predictable defaults in place. Review the applicable configuration and hardening requirements in the current published PCI DSS to confirm the full range of defaults that must be addressed for a given system type.
How do we identify default accounts and passwords across our environment in the first place?
A practical approach is to inventory the system components in scope and then consult each vendor's documentation for the accounts, credentials, and settings shipped by default. Configuration scanning tools and secure-configuration benchmarks can help flag known defaults, and manual review is often needed for devices, applications, and services that scanners do not cover well. Because scanners can miss custom or embedded defaults and may produce false results, treat automated findings as inputs to verification rather than a complete answer. Maintaining an authoritative inventory of components and their default accounts supports repeatable checks over time.
What should we do when a default account cannot be removed or renamed because the system requires it?
When a vendor requires a specific default account for the system to function, the account generally cannot simply be deleted. In that case, common hardening steps include changing the default credential to a strong, unique value, restricting the account's privileges and access to only what the system needs, disabling interactive or remote login where feasible, and applying the vendor's documented hardening guidance. Document why the account must remain and what compensating measures secure it. Confirm the specific handling expectations against the current published PCI DSS, since accepted approaches for accounts that cannot be removed are defined by the standard's requirements.
How can we keep default accounts from reappearing after software updates, reimaging, or new deployments?
Defaults can be reintroduced when systems are patched, reimaged, restored from a baseline, or newly provisioned. To reduce this, incorporate default-account handling into hardened build standards and golden images, apply configuration management so remediated settings are enforced rather than manually set, and include verification of defaults in change management and post-deployment checks. Periodic re-scanning and re-validation help catch defaults that return after updates. This is a recurring configuration-management concern, not a one-time task.
How do we evidence to an assessor that default accounts and passwords have been addressed?
Assessors typically look for a combination of documentation and observed evidence. This can include configuration and hardening standards that specify how defaults are handled, an inventory of in-scope components, records of settings changes, and results from configuration reviews or scans. During assessment, they may inspect sample systems, interview responsible personnel, and observe that default credentials do not permit access. Because the exact evidence and requirement wording differ between versions, align your documentation and testing to the applicable requirement in the current published PCI DSS and be prepared to demonstrate the control on representative systems rather than only asserting it.

Common misconceptions

Changing default passwords means only user-facing login accounts need attention.
Default security parameters extend well beyond login passwords. Items such as default SNMP community strings, default keys, and unnecessary enabled services also require review, because leaving any of them unchanged can provide an avenue for compromise.
If a default account is disabled by the vendor, it can be ignored.
Default accounts should be identified and managed regardless of their initial state. Accounts that appear disabled may be re-enabled during updates or reconfiguration, so they should be inventoried, removed where possible, or otherwise controlled and monitored.
Addressing default accounts and passwords is solely a PCI DSS concern and unrelated to other standards.
While PCI DSS addresses removing or changing vendor-supplied defaults for in-scope components, secure handling of defaults is a broad configuration hygiene practice that may also intersect with other frameworks. Confirm the specific requirement and wording against the current published version of the applicable standard, since numbering and phrasing differ across versions.

Best practices

Maintain an inventory of default accounts and default security parameters for each type of system component in scope, so nothing is overlooked during deployment or reconfiguration.
Change all vendor-supplied default passwords and remove or disable unnecessary default accounts before a system is placed into a production or connected environment.
Review and change other default security parameters, such as SNMP community strings, default keys, and default configuration flags, as part of a documented hardening baseline.
Disable or remove unnecessary default services, functionality, and enabled features to reduce the attack surface presented by out-of-the-box configurations.
Re-verify default account and parameter settings after updates, patches, or reconfiguration, since these processes can reintroduce or re-enable defaults.
Validate hardening controls against the current published version of the applicable standard rather than assuming a fixed requirement number, and document the configuration standards applied.