The Dependency You Forgot About: Lessons from the Show Floor and the Morning After
Earlier this month, I spent a day at Infosecurity Europe – one of the largest and most significant cybersecurity gatherings in the world. Travelled up from Cornwall Monday, navigated a tube strike, and arrived at ExCeL to find the show floor already buzzing. One day wasn’t enough. The calibre of keynotes, the depth of the workshops, and the conversations you fall into at the stands could easily fill a week.
But the most instructive moment of the two days didn’t happen at the conference.
It happened the morning after, at my desk in Cornwall.
A Perfect Demonstration
By mid-morning on Wednesday, a Looker Studio community connector we rely on for client reporting had silently broken. No warning. No error that pointed to anywhere useful. Just reports that wouldn’t load – and a set of client deliverables due this week..
I’d spent the previous day in sessions on third-party dependency risk. If a vendor removes a service completely, it can stop systems working, force unsafe workarounds, and even create opportunities for attackers to exploit the gap.
And then I’d walked straight into a live example.
The fix was straightforward: I replaced the community connector with an in-house Google Apps Script, documented a risk assessment, and moved on. But the point had been made – loudly, and without any help from the conference programme.
Third-party dependencies don’t announce themselves. They just stop working.
What the Conference Was Actually Saying
Three themes dominated Infosecurity Europe 2026, surfacing in keynotes, workshops, and conversations across the show floor.
1. Third-Party and Dependency Risk Is Still Being Underestimated
The attack surface has expanded well beyond your own infrastructure. Every SaaS integration, every community connector, every open-source package in your stack is a dependency – and a potential point of failure or compromise. Many organisations have excellent perimeter security and almost no visibility into what their tools are doing on their behalf.
A conversation with IASME on the show floor was particularly relevant here. They’ve introduced a relatively new service allowing bulk supply chain lookups via CSV – a practical way to start building visibility into the risk profile of your supplier ecosystem, not just your own organisation. For clients in regulated sectors – NHS, public sector, financial services – this kind of structured supply chain assurance is increasingly an expectation, not a nice-to-have.
The question isn’t whether you have third-party dependencies. Every organisation does. The question is whether you know what they are, what access they have, and what happens when they fail.
2. To Defend Against AI-Assisted Attacks, You Need to Understand How They Work
The keynote from the former CIA Head of Disguise reframed something important: the most sophisticated threats have always been fundamentally human. Deception. Trust exploitation. Identity manipulation. AI hasn’t invented a new playbook – it has industrialised the old one.
AI-assisted attacks are now faster, cheaper, and more convincing at scale. Phishing that once required hours of research can be personalised in seconds. Deepfake voice and video are accessible tools, not nation-state capabilities. The barrier to entry has collapsed.
Defending against this doesn’t require matching the attacker’s AI capability. It requires understanding the technique well enough to recognise it – and building the human and technical controls that don’t rely on spotting obvious signals that no longer exist.
3. Agentic AI Is Arriving Before the Security Models Are Ready
This was the theme that generated the most forward-looking concern. As AI agents begin to take autonomous action – accessing systems, making decisions, calling APIs on behalf of users – it becomes increasingly apparent that the trust and access control frameworks most organisations have built simply weren’t designed for this.
Who authorises an AI agent? What can it access? How do you audit what it did? These aren’t future questions. Organisations deploying AI tools today are already navigating them, often without realising it.
The security architecture needs to catch up – and quickly.
The State of the Nation
The State of the Nation address at the conference painted a picture most practitioners will recognise: the gap between threat velocity and organisational response is still widening. Not because organisations aren’t investing in security, and not because the tools aren’t there – the show floor alone makes that clear. But because the landscape is changing faster than the frameworks, policies, and culture designed to address it.
Speed of change was the undercurrent of every conversation I had.
What This Means in Practice
For our clients – particularly those operating in regulated and public sector environments – three practical questions follow from these themes:
Do you know your dependency surface? Not just your infrastructure, but the tools, connectors, APIs, and third-party services that your business processes depend on. Where are they documented? What happens when one fails or is compromised?
Are your people equipped for AI-assisted social engineering? Phishing awareness training built around spotting bad grammar is no longer sufficient. The threat has moved on. The training needs to move with it.
Are your AI governance policies keeping pace with your AI adoption? Most organisations are adopting AI tools faster than they’re updating their access control, data handling, and acceptable use policies to account for them.
These aren’t abstract concerns. One of them interrupted my Wednesday morning.
We’ll Be Back
One day at Infosecurity Europe wasn’t enough so I’ll be returning next year, for longer. The density of expertise, the quality of the conversations, and the sheer pace of the field make it essential.
If you want to discuss any of the themes above – supply chain risk, AI security, or the practicalities of dependency management in your own environment – we’d welcome the conversation.