Somewhere Over Europe
Some ideas arrive fully formed. Others sort of… leak in.
This one started somewhere between Beijing and Stockholm, half-rewatching Inception on a plane, half-asleep, and very much not trying to have any original thoughts.
There’s a scene in that film about dream architecture. Not the spectacle of it, not the emotional manipulation, but the physics. What happens when the rules people subconsciously rely on are just slightly… different.
Not broken in an obvious way. Not gravity going sideways for dramatic effect. Just wrong enough that something doesn’t resolve properly in your head.
That stuck with me. Not consciously, but enough that my brain clearly decided to keep playing with it after I’d checked out.
I woke up with two words:
Scorched Ice
Which, admittedly, sounds like nonsense. But also doesn’t. Not quite.
And that “not quite” is where it gets interesting.
The Shape of Something Wrong
Ice can be heated. That’s not unusual. But when you apply heat to ice, it melts. That’s the rule. That’s the model we carry around without ever needing to think about it .
Scorched ice breaks that model, but only subtly. The input is still valid. Heat is being applied. But instead of transitioning state, the ice is damaged in place. Burned, even. It holds its form, but carries the evidence of something that should have changed it .
That idea didn’t stay on its own for long.
It turned into a set. Not randomly, but with structure:
Scorched Ice
Shattered Water
Crushed Steam
Same substance. Different states. Each one subjected to a force that should cause a transition… and each one refusing to comply .
Water, under force, flows. It doesn’t fracture. Yet “shattered water” is immediately understandable as an image, even if it makes no physical sense. You can picture it: liquid behaving like brittle glass, splitting into pieces that somehow still aren’t solid.
Steam, under pressure, condenses. That’s basic physics. But “crushed steam” suggests something else entirely - compression without transformation. Density without collapse into liquid. A gas that holds shape under force instead of yielding to it.
Each one is just plausible enough to be uncomfortable.
Why It Works
What makes this unsettling isn’t that it’s impossible. It’s that it’s almost possible.
Nothing about these ideas introduces a new substance or a fantastical element. It’s still just water. Still governed, apparently, by the same rules. The inputs are correct: heat, force, pressure.
What’s changed is the expectation that those inputs will produce the outcomes we rely on .
And that’s where this stops being about a weird dream on a plane.
Foundations, Not Basics
For a long time, the industry default has been to talk about “doing the basics”. Patch your systems. Turn on MFA. Apply least privilege. All good advice, and none of it wrong.
But “basics” has always felt like the wrong word.
Basics are things you can checklist. Things you can complete. Things that imply a level of simplicity or even triviality.
What we’re actually dealing with are foundations. The underlying assumptions about how systems behave when you apply pressure to them .
- What does it mean for a device to be trusted?
- When is identity evaluated, and against what context?
- How long do those decisions remain valid?
- What, exactly, is a control enforcing?
These aren’t implementation details. They’re the equivalent of “ice melts under heat”.
You don’t question them, because everything else is built on top of them.
And that’s the uncomfortable part.
Foundations aren’t “foundational” because they’re easy. They’re foundational because if they’re wrong, everything above them inherits that failure .
You don’t get graceful degradation. You don’t get partial failure. You get collapse.
And more often than not, you only discover you were building on sand after the structure is already in place.
When the Model Is Wrong
The most interesting failures I’ve seen over the last few years don’t come from someone forgetting to enable a control. They come from the control behaving exactly as designed, but under a model that doesn’t hold up in practice .
A policy evaluates the device state - but only at a specific point in time. A token is issued with certain guarantees - but continues to be valid long after those guarantees have changed. A trust signal is assumed to be bound to something physical - but is actually derived from something far more malleable.
From the outside, everything looks fine. The inputs are correct. The system is behaving as expected.
And yet the outcome is wrong.
It’s scorched ice. Shattered water. Crushed steam .
This is also where “by design” quietly becomes a problem.
Because the system is behaving as designed.
The issue is that design is based on a model - a set of assumptions about identity, context, and boundaries - that doesn’t always hold in the real world.
“By design” doesn’t mean safe. It means predictable… within the limits of the assumptions that shaped it.
And if those assumptions are wrong, then the system isn’t broken. It’s just consistently producing the wrong outcome .
Identity Is Not Static
We tend to treat identity like a fixed property. Something that can be established, verified, and then relied upon. But modern identity systems don’t really work like that anymore.
They’re distributed across services. They’re represented through tokens. They’re evaluated in fragments, often at different times, by different components, each with their own partial view of reality.
And still, we carry the assumption that:
if the control is applied, the risk is reduced
That’s only true if the control is operating on a complete and accurate model.
The Subtle Failure Mode
What makes this difficult is that nothing appears obviously broken. There’s no alarm bell that goes off to tell you that your mental model no longer matches reality. Instead, you get systems that behave correctly… right up until they don’t .
The logs look clean. The policy executed. The authentication succeeded under the defined conditions.
Those conditions just weren’t the ones you thought they were.
EleMENTAL
That’s why this idea stuck.
Not because it’s abstract or philosophical, but because it’s a clean way of describing something very real:
we trust foundational behaviour without continuously validating the assumptions behind it .
Water is simple. Until it isn’t .
Identity is simple. Until it isn’t .
Security is straightforward. Until it very much isn’t .
Maybe the problem isn’t that we’re asking the wrong questions.
It’s that we’re asking them too late.
Before you ask what can go wrong, it’s worth asking:
- What assumptions am I relying on?
- When are they evaluated?
- How long do they remain true?
- What happens when they don’t?
Because if those answers aren’t clear, everything that follows is built on interpretation, not certainty .
If this seems very similar to Adam Shostack’s 4 Steps of Threat Modelling, that’s deliberate - my version is the same pattern… just shifted down a layer
Instead of modelling threats, I’m modelling foundations…
Closing Thought
We’re comfortable reasoning about systems when the rules are stable. But the real world isn’t static, and neither are the systems we build on top of it. So maybe the question isn’t whether you’ve done the basics .
Maybe it’s whether you’ve ever stopped to ask:
what if the thing I’m relying on… doesn’t behave the way I think it does ?
Because by the time you find out the answer in production, you’re no longer asking the question. You’re dealing with the consequences.
And at that point, it’s not about whether you did the basics. It’s about whether the thing you built them on was ever true to begin with .