The argument
Temporary Workarounds Have Gravity
A workaround becomes dangerous when other systems begin depending on it faster than the organization documents, governs, or removes it.
The field pattern
A legacy jump host survives one migration because two administrators still need it. Then monitoring uses it. Then the vendor support procedure references it. Then its network path is copied into a new environment. Removal now feels risky because nobody knows which invisible dependencies will fall with it.
Why it matters
Gravity converts a bounded exception into shared infrastructure. The security question is no longer whether the workaround was reasonable when created; it is whether the expanded dependency graph is understood and controlled now.
As dependencies accumulate, scope and testing expand with them. The exception becomes harder to assess, patch, segment, evidence, and replace precisely because the organization delayed measuring its pull.
Questions that expose the Wack
- What has connected to this workaround since its approval?
- Which templates or procedures now reproduce the dependency?
- Who can authorize a new dependency—and who can refuse one?
- What observable condition triggers removal?