Defaults & Workarounds
When I took over for someone who'd left, one of the first things I started finding was cables. Video cables still seated in their wall mounts. Power bricks plugged into live outlets with nothing at the other end. Equipment gone, connections left behind. It looked like someone had meant to come back and finish the job. They never did.
Nobody decided to leave them there. That's the thing. It wasn't a choice. It was the absence of one. The device got pulled, the ticket got closed, and whatever was still plugged into the wall just became part of the environment. Invisible. Inherited. Eventually, normal.
That's how temporary becomes policy. Not through any deliberate decision, but through the slow accumulation of things nobody ever came back to close out.
It's not laziness. It's the absence of a forcing function.
The tech who left those cables wasn't careless by nature. He was probably moving fast, managing more than he should have, and operating in an environment with no mechanism to force the question. Nobody was checking. There was no process that asked: is this temporary, and if so, when does it get resolved? So it didn't get resolved. It got inherited.
This is worth sitting with, because the instinct when you walk into something like that is to blame the person. But the person is usually a symptom. The real failure is structural. When there's no forcing function: no ticket that stays open, no audit that catches it, no standard that defines done, temporary configurations don't get revisited. They calcify.
Setup → Forgotten → Depended Upon → Defended. By the time someone wants to remove it, it's load-bearing. Nobody knows what touches it. Everyone's afraid to find out.
And the physical layer is actually the easy version of this problem. You can see a dangling power cord. You cannot see a vendor account that nobody owns.
The credential nobody inherited.
Vendors ship equipment with defaults. That's expected. What's less expected is how often those defaults survive the handoff.
The pattern goes like this: a vendor tech arrives, stages the device, configures it with their standard credentials, verifies it works, and hands it off to IT. IT inherits a device that's functional, on the network, checking in. It goes into the asset register and the ticket closes. What doesn't get documented is that vendoradmin with a password the vendor has used on every deployment they've ever done is still sitting on that device. It's not in your password manager. It's not in your change log. It belongs to nobody, and it can be used by anyone who knows the vendor's defaults. After a certain scale of deployment, that's not exactly a secret.
Printers and MFPs are the most common example because they're everywhere and nobody thinks about them. But the same pattern shows up in managed switches, building systems, specialty lab equipment, anything that gets stood up by a vendor tech and handed to IT as a working unit. The configuration that vendor left behind isn't your configuration. You just inherited the keys.
Vendor defaults aren't edge cases. They're essentially published. Any attacker who knows which vendor services your environment knows exactly where to start. The credential is just waiting on a device you probably don't think about.
Even regulated environments aren't immune.
You might assume that environments with formal change control, the kind where nothing moves without a documented approval, would catch this. And those controls do a lot of good. But they tend to apply to things your team does. What happens before the handoff, in the vendor's staging process, is often outside the scope of your change management entirely.
The gap isn't in your controls. The gap is in the moment before your controls start. Equipment arrives configured. Your process takes over from there. If nobody asks what the vendor left behind, it doesn't get asked. The forcing function exists. It just doesn't reach back far enough.
This is one of the harder problems in regulated environments, because the discipline is real and the intent is right. But a credential baked in at delivery, before your change control could touch it, can sit quietly for years inside an otherwise well-managed environment. Not because anyone missed it. Because the process was never designed to look for it.
Defaults are an identity problem at root.
Whether it's a dangling power cord or a vendor credential, the underlying failure is the same: something that should be owned isn't. The cable belongs to no active ticket. The account belongs to no person, no role, no team. There's nobody to call. There's nothing to revoke. The thing just exists, outside the map.
Identity-first infrastructure means asking ownership questions before anything else. Who owns this access path? Who is this credential attributable to? What happens if this account needs to be revoked? Can we actually revoke it, or do we not know where it lives? If you can't answer those questions, you don't have a configuration. You have a default that someone else made, sitting in your environment, waiting.
Mature environments don't just have better defaults. They have a deliberate practice of revisiting the ones they inherited.
That means credential audits that include vendor-configured accounts. Asset reviews that go beyond "is it on the network" to "do we know how it was configured and by whom." Onboarding checklists for new equipment that explicitly ask: what did the vendor leave behind, and have we replaced it with something we own?
It's not glamorous work. It's exactly the kind of thing that's easy to defer because nothing is visibly broken. That's the whole problem. Temporary configurations don't announce themselves. They just wait.
The one question worth asking.
I've walked into enough environments to know that the physical layer tells you a lot about the logical one. If you find cables plugged into nothing, you should probably go check the credential store. The same culture that leaves a power brick in the wall for six months after the device is gone is the same culture that inherits a vendor account and never changes it. These aren't isolated failures. They're symptoms of the same missing habit.
For every configuration your team inherits, physical or logical, ask one question: did we make this, or did we just never change it? If the answer is the second one, that's where you start.
Defaults and workarounds exist to get things moving. That's legitimate. The risk isn't using them. The risk is treating the absence of a problem as evidence that everything is fine. The cable is still in the wall. The account is still active. Nothing has gone wrong yet. That's not the same as nothing being wrong.