It’s 2025. Why Are Default Credentials Still a Threat?
This article is part of a series unpacking the NSA/CISA Top 10 Cybersecurity Misconfigurations through the lens of real-world breaches and assessment findings. Each post breaks down how these issues show up in practice, how attackers take advantage, and what defenders often overlook.
This entry covers Misconfiguration 1: Default Configurations of Software and Applications
There’s a persistent myth in cybersecurity that default credentials are only a problem for small, immature, or legacy environments. The reality is more uncomfortable. I’ve investigated breaches at well-funded organisations with modern infrastructure and capable teams. The root cause was a vendor-supplied login left unchanged. Not because of laziness, but because of drift. Because we assumed it was already onboarded. Because it wasn’t “in scope” for anyone to check.
From a consulting and incident response perspective, this misconfiguration remains one of the most quietly devastating. It shows up in unexpected places. The GlobalProtect portal left behind after a migration. The Nutanix hypervisor deployed with its original password. The printer fleet using domain creds to scan to email.
In each case, attackers did not need malware. Just patience, enumeration, and a little luck. And if you are in Aotearoa New Zealand, do not assume geography makes you immune. The gap between what is assumed and what is enforced is where compromise still lives.
TL;DR:
Default credentials are not a legacy risk. They are a live attack surface in 2025. Attackers know where to look, and too often, our defences assume someone else took care of it. If it has not been onboarded into your PAM, segmented, or rotated, it is still in play.
What This Looks Like in Practice
This misconfiguration doesn’t announce itself. It hides in the seams. A firewall configured in a rush for branch connectivity. A Citrix appliance set up by a vendor, never handed over. An out-of-band management interface still running with the manufacturer’s login. These are not rare. They are routine. And attackers know it.
In one APAC breach I supported, the attacker gained access to a GlobalProtect VPN using admin/admin. It was intended as a temporary deployment during COVID-era remote access expansion. The box was never decommissioned. Once inside, the attacker harvested credentials, pivoted laterally, and bypassed multiple layers of detection. No malware. Just a credential and a service no one remembered.
At a global law firm, the foothold came through Nutanix. The hypervisor credentials had never been rotated from nutanix/4u. From there, the attacker accessed the virtualisation layer and escalated across domains. This was a team with CyberArk deployed. The account simply wasn’t onboarded.
These are not edge cases. They are structural assumptions that went unverified. I have seen default credentials in:
Firewalls and SD-WAN gear, especially at remote sites
VMware vSphere, Nutanix Prism, and IPMI/iLO/iDRAC consoles
Printers and MFDs configured to authenticate with domain accounts
“Temporary” VPN or VDI portals left behind after projects
Dev, UAT, and lab environments with prod access paths
The breach path doesn’t always start with code. Sometimes it starts with paperwork that never got followed up. Or a vendor install that was “someone else’s responsibility.” And by the time we respond, the attacker has already moved on to the parts of the network we thought were protected.
Where to Start Looking (and Stop Assuming)
Most teams already know that default credentials are a risk. The problem isn’t awareness. It’s assumption. We assume someone rotated the credentials. We assume the device was decommissioned. We assume the portal was locked down. Assumption is the attack surface. Here’s what I’ve found effective in both proactive assessments and incident response:
Vault everything, including the weird stuff that nobody owns
If it can be logged into, it needs to be vaulted. That includes firewalls, printers, KVM switches, hypervisors, and that dusty Avaya admin panel still running in the corner. If the credentials are still admin/admin, you do not control the box. What about that SSH key? Vault that too.
Jump hosts are your friend
Full PAM deployment may be aspirational. That’s fine. Start with a jump server. Force all privileged access to route through it. That gives you a place to log from, segment from, and revoke from. If you’re feeling extra mature, enforce the jump servers with micro-segmentation tooling, but most EDR’s can manage the host firewalls now, and so can GPO’s if it is a Microsoft shop.
Default usernames should be noisy, like a canary
Accounts like admin, root, nsroot, setup, or vendor-supplied logins should never be used in routine operations. If they show up in logs, alert. If they’re used interactively, investigate. All privileged access should occur through individual, named accounts that are separate from the user’s daily identity. The same account that checks email should not be used to log into a firewall. Integrate with SSO where possible. If Active Directory is involved, enforce LDAPS so you are not broadcasting the passwords across the network in clear-text.
Built-in admin accounts should be treated as break-glass only. Vault them. Monitor them. Alert on every use. If someone logs in as root, the security team should know within seconds.
Assume drift until verified, never trust old audits
Configuration drift happens silently. Rebuilds, migrations, handovers, or temporary workarounds often undo secure setups. If a device was reviewed last year, it still needs to be checked again. Especially after outages or upgrade cycles.
Include dev and UAT environments in your scope
Dev and test environments often share identity paths or trusts with production. I’ve seen domain trust extended into “lab” zones that nobody monitored. If an attacker can get in through UAT, prod is next.
Scan like an outsider, then confirm like an insider
Start with external discovery. Use attack surface management tools or old-fashioned port sweeps. What is exposed to the world that shouldn’t be? Then take that internal. Find the forgotten, default, or orphaned services. They are usually there.
Final Thoughts
Default credentials are not an edge case. They are common, recurring, and fully preventable. They persist because ownership is unclear, tools are misaligned, or assumptions go unchallenged. Not because teams are careless, but because nobody thought to check after the project was delivered.
Attackers know how to find these footholds. The login is predictable, the service is exposed, and the breach path is often one step away from escalation.
There’s no silver bullet here. It comes down to discipline. Every appliance, portal, and out-of-band management interface should be treated as part of your privileged environment. Rotate the credentials. Segment the access. Monitor the use. Passkeys will be magical in the long run. But until vendors support them across firewalls, printers, hypervisors, and remote access tools, default credentials will keep showing up in breach reports. This is not a future-state problem. It is a present-tense one.
Get in touch