A factory-set password is published in a manual, a support forum or a scanner wordlist long before the device reaches your rack, so leaving it in place hands out a working login to anyone who looks. D3-CDP Change Default Password is the MITRE D3FEND countermeasure for that gap. D3FEND defines it as "Changing the default password means replacing the factory-set credentials with a strong, unique password before the device is deployed, preventing unauthorized access." It sits in the Harden tactic as a child of Strong Password Policy. This card covers what D3-CDP hardens, the ATT&CK techniques D3FEND relates it to, where it is applied, how to prove no defaults remain, and where the control runs out. It is written for infrastructure, OT and identity engineers who own device onboarding and for auditors who test it. For incident patterns and regulation in depth, see the Default Credential Breaches Lessons Guide.
Key takeaways
- Timing is the control. D3FEND's own considerations say the change should happen before the device is brought online, because a default is exploitable from the first minute it is reachable.
- The artefacts are Password, User Account and OT Controller. D3FEND models D3-CDP as strengthening Password and User Account and hardening OT Controller, which is why it matters most for PLCs, appliances and embedded devices.
- Default Accounts (T1078.001) is the headline technique. CISA's Cross-Sector Cybersecurity Performance Goal 2.A targets exactly that technique and, for ICS, Valid Accounts (T0859). The dedicated ATT&CK for ICS technique is now Default Credentials (T1694.001), which replaced the revoked T0812.
- Changing one password is not the same as removing every default. Devices often carry several credential sets: web admin, serial console, SNMP communities, programming ports and vendor support accounts.
- Prove it with authenticated scans and onboarding gates. The useful evidence is a scan that tried known defaults and failed, not a ticket saying the password was changed.
D3-CDP at a glance
| Field | D3-CDP Change Default Password |
|---|---|
| D3FEND ID | D3-CDP (d3f:ChangeDefaultPassword) |
| Tactic | Harden |
| Parent technique | Strong Password Policy |
| Digital artefacts | Password (strengthens), User Account (strengthens), OT Controller (hardens) |
| What it changes | Replaces vendor-known credentials with unique, strong ones before the device or software joins a network |
| D3FEND references | CISA CPG Checklist; NIST SP 800-82 Rev 3 (section 6.2.1.4.5, Password Authentication); ATT&CK for ICS mitigation M0927 Password Policies |
| Typical implementation points | Device staging and commissioning, configuration management baselines, OT engineering workstations, network and storage appliances, software installers and container images |
| Typical verification data | Authenticated and default-credential vulnerability scans, configuration compliance reports, OT asset inventory, authentication logs for vendor default usernames |
| Effort | Low per device; moderate to sustain across procurement, field replacements and resets |
| Main limitation | Hard-coded credentials, factory resets and devices that cannot change some credentials sit outside its reach |
How it works
D3FEND's knowledge base entry is short: change the default password as soon as a new device is received, noting that default credentials are documented in a manual packaged with the device, published online through official channels, or published unofficially. Its two considerations are to change them before the device is brought online, and to use strong, complex passwords where the technology allows. The parent, Strong Password Policy, sets the rules the new password has to meet; D3-CDP is the specific act of leaving the vendor's shared value behind. See D3-SPP Strong Password Policy for length and complexity rules.
In practice "the default password" is usually a set of credentials. A complete change covers:
- Administrative interfaces: web console, SSH or Telnet CLI, serial or out-of-band management ports.
- Protocol secrets: SNMP community strings, IPMI or BMC accounts, and OT programming and upload passwords. CISA's advisory on Unitronics controllers lists TCP/IP, upload, INFO mode and SD card passwords as separate settings to configure in the project file.
- Service and vendor accounts: built-in support or maintenance logins, database accounts created by installers, and application admin users seeded by a setup script or container image.
- Pre-shared values: Wi-Fi keys and pairing secrets printed on labels where the label is visible to visitors.
Manufacturers can remove the problem at source. CISA's advisory AA23-335A recommends that vendors ship products without default passwords, using a random initial password or requiring a change on first use. UK law now sets a floor for consumer connectable products: the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, in force since 29 April 2024, require passwords to be unique per product or defined by the user, and prohibit unique passwords based on incremental counters, public information or unique identifiers such as serial numbers (unless derived with an accepted encryption method or keyed hash). See the UK PSTI Act Guide.
ATT&CK techniques D3FEND relates to D3-CDP
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CDP. Every row is inferred through the artefacts D3-CDP strengthens, Password and User Account, so ATT&CK techniques that act on those artefacts or their sub-types are related (D3FEND checked November 2026; each ID checked against ATT&CK v20). D3FEND shows Account Access Removal without an ID; it is T1531. The last column is NHI Mgmt Group's assessment, not part of D3FEND.
| ATT&CK ID | Technique | Inferred via | What changing defaults does (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1078.001 | Valid Accounts: Default Accounts | User Account | Direct: the vendor-known login stops working |
| T1078.002, T1078.003, T1078.004 | Valid Accounts: Domain, Local, Cloud Accounts | User Account | Partial: helps where an appliance or image ships a local or cloud admin with a known password |
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Password | Strong against wordlists of vendor defaults; none against a weak replacement |
| T1098.002, T1098.003 | Additional Email Delegate Permissions, Additional Cloud Roles | User Account | Indirect: removes a common foothold used before account manipulation |
| T1136.001, T1136.002, T1136.003 | Create Account: Local, Domain, Cloud Account | User Account | Indirect: an attacker with no default login has fewer ways to create accounts |
| T1548.005 | Temporary Elevated Cloud Access | User Account | Indirect |
| T1087.001, T1087.002, T1087.004 | Account Discovery: Local, Domain, Cloud Account | User Account | Minimal: discovery still works; discovered default accounts are no longer usable |
| T1531 | Account Access Removal | User Account | Indirect: an attacker who logs in with a default can change the password and lock owners out |
CISA's CPG 2.A also names the ICS technique Valid Accounts (T0859); in ATT&CK for ICS v20 the default credentials technique is T1694.001 Default Credentials, which replaced the revoked T0812. For the enterprise techniques in depth, see the MITRE ATT&CK T1078 Valid Accounts Guide and the MITRE ATT&CK T1110 Brute Force Guide.
Where it is implemented
| Environment | Where the change happens | Typical gap |
|---|---|---|
| Network, storage and security appliances | Staging network before production cabling; configuration templates pushed by network automation | Out-of-band management cards and SNMP communities left at vendor values |
| OT controllers and HMIs | Engineering workstation project files during commissioning; NIST SP 800-82 Rev 3 password guidance | Field replacements and spares commissioned in a hurry; programming ports exposed to remote access |
| Servers and BMCs | Provisioning pipeline sets unique BMC and local admin passwords per host, stored in a vault | Same password set on every host, which turns one compromise into all |
| Commercial software and databases | Installer prompts or post-install hardening runbook | Sample, demo and test admin users created by setup and never removed |
| Container images and cloud marketplace images | Entrypoint generates or reads a secret at first start; no credential baked into the image | Documented default admin credential in the image used in production |
| Consumer-grade and IoT devices on the estate | Onboarding procedure before network access is granted | Devices bought outside IT and connected directly |
Unique replacement passwords for devices are machine credentials and need an owner and a store. Put them in a privileged access or secrets vault rather than a spreadsheet, and treat vendor support accounts as non-human identities with named owners. See the Device and IoT Identity Guide and the Identity for OT Environments Guide.
Implementation steps
- Write the rule into procurement and onboarding. CISA's CPG 2.A calls for an enforced organisation-wide policy or process requiring default manufacturer passwords to be changed for all hardware, software and firmware before it connects to any network. Prefer suppliers that ship unique or user-defined passwords.
- List every credential per device model. From the vendor manual, record each account, community string and port password the model has, so the change is complete rather than limited to the web admin login.
- Stage on an isolated network. Configure new devices before they reach production VLANs, so the default never faces an attacker.
- Generate unique values and vault them. One random password per device and per credential, stored with the asset ID. Shared passwords across a fleet defeat the purpose.
- Gate network access on evidence. Admission to production requires a default-credential scan result with no findings, attached to the asset record.
- Handle what cannot be changed. CPG 2.A accepts documented compensating controls with log monitoring where a change is not feasible, and applying the policy to new devices first in existing OT. Isolate such devices, restrict who can reach their management ports, and alert on use of the default username.
- Cover resets and replacements. A factory reset restores the default. Make "re-run onboarding" a mandatory step in repair, RMA and field replacement procedures.
Rollback for this control is about access, not configuration: keep the new credentials retrievable from the vault and test that the device accepts them before closing the change, so an operator is not forced back to a factory reset.
How to verify it works
- Default-credential scanning: run an authorised vulnerability scanner with default-credential checks against management interfaces, on a schedule and at onboarding. A finding is a failed control, not a vulnerability to schedule for later.
- Configuration compliance: compare running configurations against a baseline that flags known vendor community strings and default account names.
- Log review: alert on authentication attempts, failed or successful, that use vendor default usernames on any management plane.
- Exposure check: confirm no management or programming port is reachable from the internet. CISA's Unitronics advisory recommends disconnecting PLCs from the public internet and placing them behind a firewall that can detect brute-force attempts.
| Metric | What it shows | Target direction (example) |
|---|---|---|
| Assets with a passed default-credential scan, as a share of inventory | Real coverage, not policy coverage | Rising toward 100% |
| Default-credential findings open longer than 7 days | Whether findings are treated as urgent | Zero |
| New devices admitted without onboarding evidence | Gate effectiveness | Zero |
| Devices sharing the same management password | Fleet-wide blast radius | Falling to zero |
| Documented exceptions with compensating controls and an owner | Honest view of what cannot be changed | Every exception reviewed at least yearly |
Limits, bypasses and failure patterns
- Exposed controllers on defaults: CISA's advisory AA23-335A describes IRGC-affiliated actors compromising at least 75 US-based Unitronics PLC and HMI devices between November 2023 and January 2024, at least 34 of them in the Water and Wastewater Systems Sector, where devices used the vendor default password or none and were reachable on their default port.
- Default left on an internal tool: in the Nissan source code leak, a Git server reachable from the internet still accepted admin/admin, and about 20GB of source code was downloaded.
- Test and admin accounts seeded with trivial passwords: in the McHire default password flaw, a test administrator account accepted 123456 as username and password. Seeded accounts are defaults in all but name.
- Hard-coded credentials: a password embedded in firmware or code cannot be changed by the operator, so D3-CDP does not reach it. Only a vendor update or isolation helps.
- Weak replacements: swapping "admin" for a site-wide pattern simply moves the guessable value. The replacement must meet the parent Strong Password Policy and be unique.
- Silent reverts: factory resets, firmware recovery and replacement units bring the default back without a change ticket.
Framework mapping
| Framework | Reference | Relationship to D3-CDP |
|---|---|---|
| MITRE ATT&CK for ICS | M0927 Password Policies | Cited by D3FEND as a reference for D3-CDP |
| MITRE ATT&CK Enterprise | M1027 Password Policies | Enterprise mitigation for password rules (NHI Mgmt Group mapping) |
| CISA CPGs | 2.A Changing Default Passwords | Same control, with T1078.001 and ICS T0859 as the risks CISA lists (ICS default credentials now T1694.001) |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management, IA-5(1) Password-based Authentication | IA-5 covers changing default authenticators before first use (NHI Mgmt Group mapping) |
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials for users, services and hardware are managed |
| UK PSTI Regulations 2023 | Schedule 1, paragraph 1 | Manufacturer-side requirement: unique or user-defined passwords on consumer connectable products |
See M1027 Password Policies for the enterprise mitigation view.
Related countermeasures
- Parent and siblings: D3-SPP Strong Password Policy sets the rules; D3-PR Password Rotation covers changing passwords over time.
- Reducing reach: D3-DRA Disable Remote Access limits who can try a default in the first place.
- Detection: D3-LAM Local Account Monitoring catches use of built-in accounts that remain.
For how D3FEND is organised, see the MITRE D3FEND Guide.
Practitioner checklist
- Make default-password change a written condition of network access for all hardware, software and firmware.
- Record every credential each device model ships with, including SNMP, BMC, console and programming passwords.
- Configure new devices on an isolated staging network before production.
- Generate a unique password per device and credential and store it in a vault with the asset ID.
- Require a clean default-credential scan before admission, and rescan on a schedule.
- Add re-onboarding to factory reset, repair and replacement procedures.
- Remove or re-password demo, test and seeded admin accounts created by installers and images.
- Document devices that cannot be changed, isolate them, and alert on their default usernames.
Standards and references
- MITRE D3FEND: Change Default Password (D3-CDP)
- CISA: Cross-Sector Cybersecurity Performance Goals
- CISA: AA23-335A IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors
- NIST: SP 800-82 Rev 3, Guide to Operational Technology (OT) Security
- UK Government: PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1
- MITRE ATT&CK: M0927 Password Policies
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: Default Credential Breaches Lessons Guide · OT Security Guide · IoT Security Guide · MITRE D3FEND Guide