Temporary Changes, Permanent Risks

There’s a phrase that should make every security professional’s ears perk up: “We changed it temporarily for testing.”

I recently came across a situation where a configuration change was made to troubleshoot an issue. The change was small, seemingly harmless, and absolutely intended to be reversed once testing was complete. But that change quietly opened a privilege escalation path that didn’t exist before.

I’m going to keep the details vague here intentionally. What matters isn’t the specific environment or the exact change. What matters is the pattern, because this pattern plays out everywhere, constantly.

The “Just for Now” Trap

Here’s how it usually goes. Something breaks, or something needs to be tested. An engineer loosens a permission, disables a control, or adds a temporary credential to get past a blocker. The intent is always the same: fix the thing, then put it back.

But “putting it back” requires someone remembering. It requires the change being documented. It requires the person who made the change to actually be the one who reverses it, or for a handoff to happen cleanly. In practice, at least one of those steps fails more often than anyone wants to admit.

And even when the change does get reverted, there’s the window. The gap between “changed for testing” and “restored to production state” is real time during which the environment is vulnerable. Maybe it’s an hour. Maybe it’s a weekend. Maybe it’s three months because the ticket got closed and everyone assumed someone else handled it.

Attackers Don’t Need a Lot of Time

One of the things that gets drilled into you doing penetration testing is that attackers are opportunistic. They don’t need your environment to be permanently misconfigured. They just need to be looking at the right time.

If an attacker already has a foothold, even a low-privileged one, they’re enumerating constantly. They’re checking what they can access, what permissions they have, what’s changed since last time. A temporary relaxation of controls is a gift. They don’t know it’s temporary. They don’t care. They see a path that wasn’t there yesterday, and they take it.

This is what makes the “it was only temporary” justification so dangerous. It assumes the threat model operates on the same timeline as your change management process. It doesn’t.

The Real Problem Is Process

The change itself isn’t usually the problem. Sometimes you genuinely need to adjust something to diagnose an issue. The problem is when temporary changes bypass the same controls that permanent changes go through.

If a production configuration change requires a review, an approval, and a documented rollback plan, then a “temporary” change should too. The risk doesn’t care about your intent. A misconfiguration is a misconfiguration whether it was done deliberately for testing or accidentally by a junior engineer.

Some things that help:

Time-boxed changes with automated rollback. If the change has to happen, make it expire. Don’t rely on someone remembering to undo it.
Treat test changes like production changes. If it touches a production system, it gets the production process. No exceptions for “just testing.”
Alert on permission changes. If a privilege boundary shifts, someone should know immediately, not whenever the next audit happens.
Assume someone is watching. Because in a compromised environment, they are.

The Takeaway

Every environment has its own version of this story. A firewall rule that was supposed to be temporary. A service account that got extra permissions “just for a migration.” A debug mode that never got turned off.

The lesson isn’t that you should never make changes for testing. The lesson is that every change to a production environment, no matter how temporary the intent, carries real risk for exactly as long as it exists. Treat it accordingly.

The attackers already are.