SCADAPASS: a default and hardcoded credential list for ICS equipment

What the list covers and how it is structured

The SCADA StrangeLove Default/Hardcoded Passwords List is a curated list of default and hardcoded credentials for ICS and SCADA equipment, and the README names the categories it covers: PLCs, DCS, RTUs, HMIs, SCADA software, industrial network gear, protection relays and building automation systems.

The important sentence for anyone using it is that every entry carries a source URL, and the README specifies that these are vendor documentation or security research. That is what separates this from the kind of unsourced credential dump that circulates on the internet, and it is the property that makes the list usable in an audit where you have to justify every finding.

The main file is scadapass.csv, and the README describes it as the main list with 341 entries across 107 vendors. The columns are Vendor, Device, Default password, Port, Device type, Protocol and Source.

Those seven columns are the design of the list. Vendor and Device identify the product. Default password is the credential. Port and Protocol tell you how it is actually exposed, which matters because the same product can be reachable over Modbus TCP, Ethernet/IP, HTTP or a proprietary protocol on different ports. Device type lets you group findings by layer of the plant. And Source points at the document or advisory that establishes the credential, so a reviewer can check it rather than take it on trust.

The repository is small on purpose: .gitattributes, .gitignore, README, scadapass.csv and scadapass_fixed.csv. There is no code, no scanner and no framework. It is data, and the value is entirely in the data's provenance and structure.

The homepage is scada.sl, and the README gives a contact address, [email protected], and a handle @scadasl, for corrections and additions.

The second file, and why it matters as much as the first

The companion file scadapass_fixed.csv is the part that makes this repository worth reading carefully rather than just downloading.

The README describes it as a companion list of FIXED and ELIMINATED default passwords: devices that no longer ship with a usable shared default, because of a forced first-login change, unique per-device label passwords, or vendor-patched hardcoded credentials. And it carries an instruction in capitals: do not list these as having working defaults.

That instruction exists because the failure mode is predictable. A list of default credentials gets copied into a scanner, and a scanner does not know that a particular model had its default removed in a firmware update. The result is a report full of findings that are no longer real, and a team that stops trusting the report.

So the two files together encode a piece of knowledge that neither file has alone. scadapass.csv says what the credential is. scadapass_fixed.csv says when it stopped being true. An audit that reads only the first file produces false positives; an audit that reads both produces findings that survive review.

The mechanisms listed for elimination are worth noting because each one is a different kind of vendor response. A forced first-login change requires the operator to set a credential at commissioning, which pushes the work onto whoever does the installation. Unique per-device label passwords move the credential onto the physical label of the unit, which is a supply-chain and physical-access problem rather than a software one. A vendor-patched hardcoded credential is a firmware change, and it is the only one of the three that can be verified by checking a version number.

For an assessor, that last distinction is the practical one. A patched credential is verified by version; a forced change is verified by configuration; a label password is verified by a site visit.

What the 2026 update added, and the sourcing convention

Release 1.3, published in October 2026, is described as the first major update since 2016, with 126 new entries covering the 2016 to 2026 period. That decade gap is the whole story of the list: a curated list that nobody had refreshed for ten years would have been close to worthless, and one that has been is a real asset.

The scope of the additions is broad and, more usefully, structured by plant layer.

On the PLC and DCS side the update covers Siemens SCALANCE XM and XR, RUGGEDCOM ROS and NMS, Rockwell Stratix and PanelView, Schneider Modicon M580, Easergy P3 and PowerLogic PM5500, Altivar dPAC, ABB Relion 615, REX615 and REX640, Emerson ROC800 and FB107, Honeywell Experion and ControlEdge, and from Mitsubishi, Omron, Beckhoff, WAGO PFC, Bosch Rexroth ctrlX, CODESYS and Phoenix Contact mGuard and PLCnext.

SCADA and HMI software is covered for Ignition, Advantech WebAccess, Weintek EasyBuilder Pro, JCI Metasys, Siemens Desigo CC and PXC, and GE EnerVista. Industrial networking adds Moxa with MX-NOS, NPort, ioLogik and MXview, Teltonika RutOS, Sierra Wireless AirLink, Ewon Flexy and Cosy+, Red Lion Crimson and N-Tron, Cisco IE, Hirschmann HiOS and InHand. Power and protection relays include SEL relays and RTAC, GE Multilin UR, and Eaton PXG and PXM. Building management covers Tridium Niagara 4 with JACE-8000 and 9000 and Edge 10, Honeywell WEBs, and Distech ECLYPSE.

There is also a category of hardcoded credentials tied to published CVEs: Emerson DeltaV with CVE-2022-29962 through CVE-2022-29965, Honeywell ControlEdge and Safety Manager, and Yokogawa STARDOM and CENTUM VP with CVE-2025-7741.

The sourcing convention is the detail to copy if you build something similar. New entries are sourced from official vendor documentation and security research, meaning CISA ICS advisories and CVEs, and the Source column in most new entries is prefixed with [official] or [research]. A reader can tell at a glance whether a row came from a manual or from an advisory, and those two kinds of source carry different weight.

The release history also records who did what: release 1.1 by Oxana Andreeva, and release 1.3 in October 2026 by Sergey Gordeychik, with thanks to Oxana Andreeva and Jericho of attrition.org.

How to work with the list without turning it into a scanner

There is no installation step, and that is worth saying plainly rather than inventing one. The repository is two CSV files and a README, the primary language is not stated, the licence is not stated either, and the default branch is master with the last push on 2026-10-04.

So the workflow is: fetch scadapass.csv and scadapass_fixed.csv, and work with them as data.

The shape of a careful audit using this list is narrower than scanning. You already know the equipment you own and what is connected to your network, so the list's job is to tell you which of those devices might still accept a factory credential, and to give you the source to check when it does.

Two habits keep that honest. First, check the fixed list for the same vendor and device before testing anything, because the fix may already have shipped. Second, confirm the finding against the vendor document rather than against the list alone, since the Source column exists precisely to let you do that.

The Port and Protocol columns are what turn a list into a finding. A credential that is only reachable over a proprietary protocol on a management port that is not routed is a very different finding from a web interface credential on a port that is exposed to the internet, and the list gives you the fields to make that distinction without guessing.

The Device type column supports a second cut, which is grouping by plant layer so that a PLC credential, an HMI credential and a building management credential are reported to different owners. In a large site those are different teams, and a single undifferentiated credential report tends to get owned by nobody.

What the list deliberately does not give you is any tooling. There is no scanner, no protocol implementation and no exploit code here, and the format itself, a CSV with a Source column, is designed for someone reading it and checking it.

Where the list is the wrong tool

There are three limits, and the first is about what a default credential list can tell you about your estate.

The first is that it is a lookup, not an assessment. It tells you what credentials are known to exist for a given product. It cannot tell you whether your unit is reachable on the port in question, whether it is still on the factory credential, or whether someone has changed it and not recorded that. A list is the input to a test, not the test itself, and an audit that reports list entries as findings without testing anything has produced a worklist, not a result.

The second is that the data has a currency problem built into its design. The 1.3 release closed a ten-year gap, but the list is a snapshot of vendor documentation and advisories, and a vendor can ship a firmware update at any time. The Source URL and the [official] and [research] prefixes let you check an entry, and checking is the only defence against reporting a credential that was patched last month.

The third is the legal and safety boundary, and it is sharper here than for consumer devices. These are industrial control systems. A default credential on an HMI in a water treatment plant or a building management system is a serious finding, but so is an unauthorised connection attempt against it, and some of these devices have no rate limiting, no logging, or worse, physical consequences for a malformed request. Any use of this list against a system you do not own or have written authorisation to test is out of scope, and the licence is not even stated in the repository, so there is no grant of permission for any use at all.

The honest alternative for the same goal is to build your own inventory first. An asset list of what is actually on your network, with model numbers and firmware versions, turns the credential question into a lookup against a finite set rather than a scan of everything you can reach, and it is the step that separates an audit from a sweep. The second alternative is the vendor's own documentation for the models you own, which the Source column already points at for many rows, and that route is slower and produces fewer false positives.

Where a broad sweep is genuinely required, the tool to compare against is a vulnerability scanner with industrial coverage rather than a credential list. The difference in approach is what gets matched: a scanner probes what is present and reports on it, while this list tells you what might be accepted if you probe. Used together, the inventory narrows the list and the list tells the scanner what to check for, and either one on its own leaves you guessing.

Editorial conclusion

Adopt SCADAPASS if you are auditing an ICS or building automation estate and want a sourced starting list of factory credentials to check against, since each row carries a vendor document or advisory behind it. Do not adopt it as a scan target list for equipment you do not own, and do not treat its contents as current fact without checking the vendor, because a default changes with a firmware release. Before you use it, read the fixed-credentials file as well, so your audit does not report devices that no longer ship with a working shared default.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. scadastrangelove/SCADAPASS on GitHub