Factory default and example credentials keep opening production systems, because nobody owns the account that shipped with the product. The pattern is the same whether the system is an AI hiring platform, a Git server, a PLC in a water utility or an AI gateway: a login such as admin/admin, 123456 or a documented example key survives installation, the system is reachable from the internet, and an attacker or researcher simply signs in. What has changed is speed: in 2026, AI agents tested default and weak credentials at machine speed across whole estates. This guide draws lessons from the default credential incidents in the NHI Mgmt Group breach database, explains how they differ from hard-coded credentials and general misconfiguration, and sets out how to find, remove and monitor default accounts. It is for security engineers, platform owners, OT and IoT teams, and anyone who installs third-party software.
Key takeaways
- Default credentials are an ownership failure, not a password strength failure. The account belongs to the product, not to a person, so it is never reviewed, rotated or removed.
- Test, demo and example accounts are the usual culprits. McHire's 123456 account was on a test restaurant; LiteLLM's sk-1234 is a documented example key that also works in production.
- Internet exposure turns a weak default into a breach. Every case below combined a default credential with an administrative interface reachable from the internet.
- Attackers now automate the guessing. The JADEPUFFER and Taiwan incidents in 2026 showed AI agents trying factory logins and predictable passwords within seconds of finding a service.
- Prevention has moved to the manufacturer. The UK PSTI regime and ETSI EN 303 645 ban universal default passwords on consumer connectable products, and CISA's Secure by Design alert asks all manufacturers to eliminate them, but buyers still inherit everything already deployed.
What counts as a default credential
MITRE's CWE catalogue separates the problem into precise weaknesses, and the distinction matters for who has to fix it.
| Weakness | Definition | Who can fix it | Example in the breach database |
|---|---|---|---|
| CWE-1392 Use of Default Credentials (children CWE-1393 Use of Default Password, CWE-1394 Use of Default Cryptographic Key) | The product uses default credentials, such as passwords or cryptographic keys, for potentially critical functionality | The operator, by changing or disabling the default at install; the vendor, by forcing a change | Nissan Bitbucket on admin/admin; MinIO minioadmin in JADEPUFFER; LiteLLM sk-1234 |
| CWE-798 Use of Hard-coded Credentials | A credential is embedded in the product code or firmware and cannot be changed by the operator | Only the vendor, through a patch | HPE Aruba Instant On access points; SAP SQL Anywhere Monitor |
| CWE-1391 Use of Weak Credentials (parent) | Credentials that are predictable or guessable | The operator and identity team, through password policy and monitoring | Taiwan government accounts with passwords built from employee IDs |
The CWE-1392 entry lists the mitigations in order of effectiveness: prohibit default, hard-coded or other values that do not vary; force the administrator to change the credential on installation; and, as a weaker fallback, have the administrator change defaults during installation or operation. The first two are vendor decisions. The third is where most organisations are, which is why the incidents keep happening.
Hard-coded credentials are a different response problem: you cannot rotate them, only patch and isolate. In the CISA Known Exploited Vulnerabilities catalogue (version 2026.10.21), 13 entries name hard-coded credentials, hard-coded keys or insecure default passwords in their title or description, including Unitronics Vision PLCs (CVE-2023-6448), SolarWinds Web Help Desk (CVE-2024-28987), Acronis Cyber Infrastructure (CVE-2023-45249) and Cisco Secure Firewall Management Center (CVE-2026-20316). Treat any such KEV entry as a patch-now item for internet-facing assets.
Lessons from the incidents
| Incident | Default or weak credential | What made it exploitable | Lesson |
|---|---|---|---|
| McHire Default Password Flaw 2025 | 123456 as both username and password on a Paradox team member login | Admin access to a test restaurant, plus an IDOR that exposed other applicants' records | Test and staff accounts in production need the same lifecycle as customer admin accounts |
| Nissan Source Code Leak 2021 | admin/admin on a self-hosted Bitbucket server | Internet-facing source control with a shared administrator account and no named owner | Change or remove default admins at install, keep source control behind SSO with MFA |
| JADEPUFFER Agentic Ransomware 2026 | MinIO factory login; an attempt to forge Nacos tokens with the documented default JWT key | Initial access through a Langflow flaw (CVE-2025-3248), then internal services left on defaults | Internal services need defaults removed too, because one foothold exposes them all |
| LiteLLM MCP Auth Bypass 2026 | Documented example master key sk-1234, which also signs session tokens | Internet-facing AI gateways; Wiz found 294 of 3,074 scanned gateways accepted the example key | Example keys in quick-start docs become production defaults unless the installer refuses them |
| Taiwan Autonomous AI Agent Cyberattack 2026 | Predictable passwords derived from employee IDs | Password spraying, then SSO into internal systems without step-up | A predictable password scheme is a default credential at organisation scale |
Two non-AI cases show the same pattern in other sectors. CISA advisory AA23-335A described IRGC-affiliated actors, under the CyberAv3ngers persona, authenticating to internet-connected Unitronics Vision Series PLCs on the default TCP port 20256 where devices had a default password or no password, affecting US water and wastewater facilities. The HPE Aruba Instant On hard-coded credentials case shows the vendor-side variant, where the operator cannot change the credential at all.
For the wider family of exposure incidents (open storage, open consoles, public databases) see the Misconfiguration Exposure Breaches Lessons Guide; this guide covers only the credential part.
Why default credentials survive
- No owner: the account was created by the installer, not by a joiner process, so it never appears in an access review. In identity terms it is an unmanaged non-human or shared identity.
- Quick-start documentation: examples such as sk-1234 or minioadmin are copied into Docker Compose files, Helm values and infrastructure code, then promoted to production unchanged.
- Test and demo tenants in production: test restaurants, demo users and staging admins live in the same environment as real data and are never decommissioned.
- Appliances and OT outside identity tooling: PLCs, cameras, storage arrays and network devices keep local accounts that SSO and PAM never see.
- Change aversion: operators fear that changing a vendor default will break support access or integrations, so it is deferred indefinitely.
- Shared secrets doubling as keys: when a default value also signs tokens, as LiteLLM's master key does, an attacker who knows it can forge sessions, not just log in.
How to find default credentials in your estate
- Start from exposure: list every internet-facing administrative interface (management consoles, Git servers, object storage consoles, AI gateways, remote access to PLCs and HMIs) from your attack surface management data. These are the first priority. See the Attack Surface Management Guide.
- Check vendor defaults per product: for each product, record the documented default accounts and keys from the vendor installation guide, and test, with authorisation, whether they still work. Use authenticated configuration scanning where possible rather than login attempts against production.
- Scan infrastructure code and configuration: search Compose files, Helm charts, Terraform variables and environment files for known example values (for example sk-1234, minioadmin, admin/admin) and for empty password fields. Secret scanning tools can carry custom patterns for these.
- Inventory local accounts on appliances: export local users from network devices, storage, hypervisors, OT controllers and AI platforms and compare them with the vendor's default account list.
- Find test and demo accounts: query production identity stores and application admin tables for accounts with test, demo, trial or vendor in the name, or with no login for a long period.
- Check KEV for hard-coded credentials: match your asset inventory against KEV entries for hard-coded or default credentials and patch or isolate.
Remediation and prevention
| Control | What to do | Applies to |
|---|---|---|
| Install-time gate | Build and deployment pipelines fail if a known default or example credential is present; golden images ship with unique credentials generated at first boot | Servers, containers, AI gateways, storage |
| Disable or rename built-in admins | Where possible, disable the default admin account and create named administrators; where not, rotate the password into a vault with an owner | Appliances, Git servers, databases |
| SSO and MFA in front of admin interfaces | Put management consoles behind SSO with phishing-resistant MFA or an identity-aware proxy; remove direct internet access | Consoles, source control, AI gateways |
| Network removal | Disconnect PLCs and HMIs from the public internet and use a firewall, VPN or gateway for remote access, as AA23-335A recommends | OT and IoT |
| Separate signing keys from login secrets | Use a distinct, randomly generated key for token signing and replace shared master keys with named, short-lived tokens per caller | AI gateways, APIs, identity platforms |
| Procurement requirements | Require no universal default passwords (ETSI EN 303 645 provision 5.1-1), forced change at setup and documented default accounts | All new products |
| Predictable password ban | Block passwords derived from usernames, IDs or company names and detect spraying | Workforce and service accounts |
Rollout and rollback: change defaults in a staging copy first and confirm integrations and vendor support access still work, then change production in a maintenance window with the old credential held in the vault for a short, defined rollback period before it is destroyed. For OT devices, follow the vendor's procedure and test in a lab or on a non-critical unit first.
Small versus large organisations: a small team should focus on the internet-facing list and the install-time gate, which removes most of the risk. A large organisation should also integrate appliance local accounts into PAM, add default-credential checks to configuration compliance scanning, and write the procurement requirement into supplier contracts. See the Server Build and Golden Image Hardening Guide and the Security by Design and by Default Guide.
Regulation and secure by design
- UK PSTI regime: in force since 29 April 2024 for consumer connectable products. Passwords must be unique per product or capable of being defined by the user, and unique passwords must not be based on incremental counters, publicly available information or easily guessable patterns. See the UK PSTI Act Guide.
- ETSI EN 303 645 (V2.1.1, June 2020): provision 5.1-1 requires consumer IoT device passwords in any state other than factory default to be unique per device or defined by the user; provision 5.1-2 requires pre-installed unique passwords to be generated in a way that reduces the risk of automated attacks against a class of device.
- CISA Secure by Design alert on default passwords: the second alert in CISA's series urges manufacturers to eliminate default passwords, applying the principles of taking ownership of customer security outcomes and building leadership to achieve them.
These rules mostly cover new consumer products. Enterprise software, appliances and open-source projects are largely outside them, so enterprise buyers still need their own install-time controls.
Detection and measurement
Detect use of default accounts as well as their existence. Log every authentication to built-in administrator accounts on appliances, consoles and gateways and send it to the SIEM; any successful login to a default account name from a new source should alert. Watch for distributed failed logins across many accounts (spraying) and for bulk actions after an admin login, such as repository cloning or bucket listing.
- Default credential findings open: number of assets where a vendor default still works, split by internet-facing and internal.
- Time to remediate: median days from finding a working default to removal; internet-facing findings should be counted in hours.
- Pipeline gate coverage: percentage of deployment pipelines that block known example credentials.
- Appliance accounts under management: percentage of appliance and OT local admin accounts vaulted with a named owner.
- KEV hard-coded credential exposure: number of assets affected by KEV entries for hard-coded or default credentials that are unpatched or not isolated.
- Test accounts in production: count of test, demo or vendor accounts with access to production data.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078.001 Default Accounts; T1110.001 Password Guessing; T1110.003 Password Spraying; T1190 Exploit Public-Facing Application; T1133 External Remote Services | How defaults and predictable passwords are used for access |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management; AC-2 Account Management; CM-2 Baseline Configuration; CM-6 Configuration Settings; CM-7 Least Functionality; RA-5 Vulnerability Monitoring and Scanning; SA-4 Acquisition Process | Changing defaults, owning accounts, baselines, scanning and procurement |
| NIST CSF 2.0 | PR.AA Identity Management, Authentication, and Access Control; ID.AM Asset Management; DE.CM Continuous Monitoring | Account control, inventory and detection |
| CIS Controls v8.1 | Control 4 Secure Configuration of Enterprise Assets and Software; Control 5 Account Management | Default account management and account inventory |
| ISO/IEC 27001:2022 Annex A | 5.17 Authentication information; 8.9 Configuration management | Credential handling and secure configuration |
| CWE | CWE-1392, CWE-1393, CWE-1394, CWE-798 | Vendor-side weakness classification |
Common failure patterns
- Changing the password but keeping the account shared: a rotated admin password that five people know is still an unowned account.
- Fixing the internet-facing system only: JADEPUFFER moved from one exposed service to internal MinIO and database services left on defaults.
- Trusting quick-start configuration: example keys copied from documentation into production, as in the LiteLLM gateways.
- Leaving test tenants live: the McHire account sat on a test restaurant with access to production systems.
- Treating hard-coded credentials as a password change task: they need a patch and isolation, and a rotation ticket wastes time.
- Predictable initial passwords: organisation-wide schemes based on IDs or birth dates behave like a published default, as the Taiwan incident showed. See the Password Spraying and Credential Stuffing Defence Guide.
Practitioner checklist
- List every internet-facing admin interface and confirm no vendor default works on any of them.
- Add a pipeline check that blocks known example credentials such as sk-1234 and minioadmin.
- Disable or rename built-in admin accounts, or vault them with a named owner.
- Put management consoles, Git servers and AI gateways behind SSO with MFA.
- Remove PLCs and HMIs from direct internet exposure and change their default passwords.
- Find and remove test, demo and vendor accounts with production access.
- Match assets against KEV entries for hard-coded or default credentials and patch or isolate.
- Alert on any login to a default account name and on password spraying patterns.
- Write "no universal default passwords, forced change at setup" into procurement requirements.
Standards and references
- MITRE: CWE-1392 Use of Default Credentials
- CISA: AA23-335A IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors
- CISA: Secure by Design Alert, How Manufacturers Can Protect Customers by Eliminating Default Passwords
- CISA: Known Exploited Vulnerabilities Catalog
- ETSI: EN 303 645 Cyber Security for Consumer Internet of Things, Baseline Requirements
- UK Government: The UK Product Security and Telecommunications Infrastructure (Product Security) regime
- MITRE ATT&CK: T1078.001 Valid Accounts, Default Accounts
- Ian Carroll: McHire vulnerability research write-up
Related NHI Mgmt Group resources: Misconfiguration Exposure Breaches Lessons Guide · Securing the AI gateway itself · OT Remote Access Guide · Break-Glass Account Guide