Mark's Thoughts

A little more thought, please

markw@markwilson.co.uk (Mark Wilson) — Wed, 4 Nov 2026 00:00:00 +0000

A little more thought, please

I’ve spent most of my career working in technology, and I spend a lot of my working life online. Generally speaking, I think the Internet is a wonderful thing (social media excepted). But there are some things that really get on my nerves, ranging from minor irritations to things that make me question how we communicate and how little consideration we sometimes give to the people on the receiving end.

So, in no particular order, here are a few things that have been winding me up lately.

The language of warfare

I recently saw a LinkedIn post from a defence company proudly explaining how its engineers were working alongside the British Army to “compress its kill chain”.

Urgh. Kill chain.

I understand that defence is a serious business, and that military operations have their own terminology. I also understand that the phrase has a specific operational meaning. But there’s something deeply uncomfortable about seeing a company celebrating its contribution to making the process of killing people more efficient. Perhaps that’s the point of the terminology: abstract the activity into a process, give it a technical name, and remove the human consequences from the conversation.

And it’s not just defence. The technology industry has borrowed plenty of military language, particularly in cybersecurity. We have bastion hosts, demilitarised zones (DMZs), firewalls, red teams, blue teams, attack surfaces, threat hunting and cyber warfare. Even “kill chain” has found its way into cybersecurity.

Some of these terms have useful technical meanings, and a few have been around for decades. But does everything have to sound like a military operation? Sometimes it feels as though we’ve built an entire vocabulary designed to make protecting computers sound more macho.

I’m not suggesting we rename every firewall or abandon established terminology. But perhaps we could think a little more carefully about the language we use, especially when it starts to obscure what we’re actually talking about.

Salespeople who haven’t done their homework

I know that junior salespeople have a difficult job. They’ve been given a list of prospects, a CRM system and some targets to hit. They need to make contact, start conversations and generate opportunities. I get it. Really, I do.

But please, do some research.

My personal website and email address are not an invitation to pitch services to my employer. If you’re contacting me about something related to Node4, at least have the courtesy to use my work contact details. And, before you pick up the phone, perhaps spend thirty seconds finding out what Node4 actually does.

In the last few weeks, I’ve had someone send me a cybersecurity report as part of a pitch for their services. We have our own Security Operations Centre. Another caller started pitching IT managed services. To a managed services provider.

These aren’t obscure details buried in an annual report. They’re fundamental to what the company does. I don’t expect every salesperson to have an encyclopaedic knowledge of their prospects, but I do expect them to understand enough to establish whether their proposition is even remotely relevant. Otherwise, you’re not selling. You’re just interrupting people.

Cold emails, and the inevitable follow-ups

Then there are the unsolicited emails. “Just reaching out…”, “Following up on my previous email…”, “Bringing this back to the top of your inbox…”, “I know you’re busy…”

Yes. I am busy. And you’ve just made me busier.

I particularly dislike the assumption that a lack of response means I need reminding. Perhaps I didn’t reply because I wasn’t interested. Perhaps your proposition wasn’t relevant. Perhaps I simply didn’t want to engage. Silence is not an invitation to send another five emails.

And if you’re sending unsolicited marketing messages, provide a proper unsubscribe mechanism. Not a line at the bottom saying I can reply and ask to be removed from your list. An actual unsubscribe link.

There are rules around electronic marketing, consent and legitimate interests, and the precise requirements depend on who you’re contacting and in what capacity. But regardless of the legal position, making it difficult for someone to opt out is a terrible way to build a relationship. If I can’t easily unsubscribe, there’s a good chance your message is going straight into my junk folder.

Don’t put things in my calendar

This one really makes my blood boil. An unsolicited invitation to a webinar arrives, not as an email, but as a calendar appointment. Suddenly, something I have expressed absolutely no interest in attending is sitting in my diary.

Who thought that was acceptable?

I have a meeting booking link. People who genuinely need to arrange time with me can use it. And I’m perfectly capable of reading an email invitation to a webinar and deciding whether I want to attend. If I register, by all means send me a calendar invitation. Until then, stay out of my diary.

It’s presumptuous, intrusive and disrespectful of my time.

AI-generated presentations that all look the same

Finally, a more recent irritation: the explosion of presentations generated by tools like Claude and Copilot.

Before anyone accuses me of being anti-AI, I’m absolutely not. I use generative AI regularly, including to help structure ideas, draft content and improve my writing. There’s nothing inherently wrong with using AI to help create a presentation, either. But could we please put a little effort into the finished product?

I’m seeing more and more slide decks that have clearly been generated by an AI tool and then presented without much further thought. They look attractive enough at first glance, with clean layouts, tasteful colours and neatly arranged content. The problem is that they all look the same. By the fourth almost-identical presentation of the week, the novelty has worn off.

What happened to corporate templates? Visual identity? Personal style? Actually thinking about how best to communicate an idea to a particular audience?

A presentation isn’t just a document. It’s a visual aid to a conversation, a story or an explanation. The slides should support the speaker, not substitute for the effort of communicating. If you’ve used AI to help with the structure, great. If it’s helped you develop an argument or identify a clearer way to explain something, even better. But at least make the effort to turn the output into something that’s yours.

Because if you can’t be bothered to put any thought into the presentation, why should I spend my time watching and listening? I could just ask an LLM myself.

And yes, I used AI to help write this

Before anyone points out the irony, yes, I used ChatGPT to help organise this rant into something vaguely coherent. The frustrations are mine, the examples are real, and the opinions are very much my own. But I had a collection of things that were annoying me, and rather than spend an evening rearranging paragraphs, I asked an AI to help turn them into a blog post.

And then I spent time editing it, because the first draft sounded rather too much like something written by ChatGPT. Too many short paragraphs, overly tidy conclusions and a tendency to explain the obvious. Sound familiar?

That’s rather the point. AI is a useful tool, but it doesn’t remove the need for human judgement, originality or a bit of personality. Whether it’s a presentation, a blog post or something else entirely, I think the person putting their name to it should still take responsibility for the finished result.

Show some consideration

I suppose what connects all these irritations is a lack of consideration for other people. Technology makes it easier than ever to communicate, automate tasks, create content and reach an audience. But the convenience of the person sending a message, making a sales pitch or generating a presentation shouldn’t come at the expense of the person receiving it.

I’m certainly not perfect, and I’m sure I’ve annoyed plenty of people over the years. But I do think we could all benefit from considering how our words and actions might be received, rather than simply taking advantage of what technology allows us to do.

Anyway, that’s enough grumbling for one day. I’m sure I’ll find something else to complain about before long.

Sovereign AI: preserving choice in an intelligent world

markw@markwilson.co.uk (Mark Wilson) — Tue, 3 Nov 2026 00:00:00 +0000

Sovereign AI: preserving choice in an intelligent world

It’s not every day that I get to present at the Red Bull Technology Campus MK-7 Events Venue in Milton Keynes. Well, last month, as part of Milton Keynes Tech Week, BletchleyAI hosted an event at this fantastic venue, and I was fortunate enough to be one of the speakers.

It was a brilliant experience, made even better by the fact that Emily Darlington, MP for Milton Keynes Central, spoke immediately before me. Emily spoke about the UK’s AI opportunity, with Milton Keynes at its heart, providing an excellent introduction to some of the issues I wanted to explore in my own 20-minute session.

I’d delivered a similar talk at BirminghamAI the previous month, but the Bletchley event gave me another opportunity to explore a subject that’s already attracting considerable attention. As organisations move beyond AI experimentation and embed it in their operations, questions about sovereignty, control and dependency are becoming increasingly important.

My talk was titled “Sovereign AI: preserving choice in an intelligent world” (slides available here). Despite the title, this wasn’t really a discussion about where to host AI models, or whether UK organisations should avoid American technology providers. It was about understanding our dependencies and retaining meaningful choices when circumstances change.

From road atlases to artificial intelligence

Twenty years ago, I kept a road atlas in my car. Today, I enter a destination into Waze, connect my phone to CarPlay and follow the directions.

It’s brilliant. But that convenience comes with dependencies on GPS, connectivity, mapping data and the organisations providing those services. Most of the time, we don’t think about any of that. Everything just works.

Of course, we’ve all seen examples of drivers blindly following their sat-nav into unsuitable roads. The technology may have provided a perfectly valid route for a car, but the driver failed to recognise its limitations or apply their own judgement.

We’re increasingly using AI in much the same way, consuming intelligence as a service, sometimes without even realising it because AI functionality is embedded in the applications and business processes we already use.

But what happens when something changes? A provider introduces new pricing, removes a capability or restricts access. Suddenly, an organisation discovers just how dependent it has become on something it doesn’t control.

Dependence isn’t necessarily the problem. Failing to recognise it might be.

AI is becoming infrastructure

Electricity, internet connectivity, GPS and cloud computing have all become capabilities we expect to be available whenever we need them. But most organisations don’t generate their own electricity, and many have moved away from running parts of their own computing infrastructure, choosing instead to consume services from cloud providers.

AI is already being consumed in much the same way. For most users, it arrives through applications and SaaS platforms, often as functionality added to products they already use. Others access models through APIs and managed services, while a smaller number develop or operate their own AI infrastructure.

As AI becomes embedded in everyday operations, losing access, experiencing service disruption or facing unexpected costs could have serious consequences. Organisations may become dependent on AI capabilities without ever having made an explicit decision to adopt a particular model or provider.

We spend plenty of time discussing which AI model performs best or what the latest agents can achieve. We should also be asking who controls the capabilities we’re becoming dependent upon, and what alternatives exist if circumstances change.

Sovereignty is about more than location

When people talk about sovereign AI, the conversation often starts with where the data is stored or where the models run. Both matter, but they’re only part of the picture.

In my presentation, I identified six areas of dependency: data, models, infrastructure, operations, economics and skills.

An organisation might run AI on its own infrastructure but still depend on external suppliers for models, maintenance or specialist expertise. Conversely, using a global cloud provider doesn’t automatically mean surrendering meaningful control.

I shared an example of an organisation that invested in local GPU infrastructure and models to gain greater control over its AI capabilities and costs. That provided more control over where processing happened, but it also introduced operational responsibilities that hadn’t been fully considered. Who would maintain the models and agents? Who would monitor performance and consumption? Who would manage security, incidents and updates?

These responsibilities don’t disappear once the hardware is installed.

There’s an interesting parallel with email. Over the past couple of decades, many organisations moved their email systems to cloud services, accepting greater dependence on external providers in exchange for reduced operational complexity. Now, in pursuit of sovereign AI, some organisations are considering bringing key infrastructure and services back under their direct control.

That may be entirely appropriate, but it means taking responsibility for operating and maintaining those services, along with the skills and costs involved. Sovereignty requires us to consider those operational dependencies alongside questions of data residency and infrastructure ownership.

Owning more technology can give us greater control, but it also brings greater responsibility.

Moving beyond sovereignty claims

As more technology providers promote their sovereign AI credentials, we need to look beyond the marketing.

“Our data stays in-country” sounds reassuring, but what about prompts, telemetry and metadata? “We run locally” tells us where the computing takes place, but not necessarily who controls the models or operates the service.

My colleague, Andy Slater, introduced me to an interesting assessment model at sovereignty.posetiv.co.uk. It provides a structured way to examine sovereignty claims, asking for evidence that can be verified rather than simply accepting a supplier’s assurances.

The approach encourages us to move from claims to evidence, verification and confidence. So, rather than treating sovereignty as a simple yes-or-no question, we should be asking who controls the service, which laws apply, what dependencies remain and whether we could realistically change providers.

The answers will vary between organisations and use cases.

Not everything needs maximum sovereignty

If I’m using AI to plan a holiday, I’m comfortable accepting considerable dependency. If it’s supporting healthcare or critical infrastructure, I’d expect a very different level of control.

Maximum sovereignty everywhere would be expensive, complicated and, in many cases, unnecessary. We need to understand the risks, make informed decisions and retain appropriate control over the capabilities that matter.

It’s much easier to preserve those choices before a dependency becomes essential.

Keeping our options open

I finished the presentation by returning to the navigation analogy. I might normally follow Waze, but I can choose another route, consult a paper map or even take the train.

Organisations need equivalent choices for AI, especially as it becomes part of their everyday operations.

Sovereign AI isn’t about owning everything. It’s about ensuring we still have choices when circumstances change.

PostScript

The Bletchley AI event was about much more than my presentation. Stephanie Okumi opened proceedings with a series of One Minute Wonders, featuring Laura Graham-Brown, Zee Bielske, Steve Lamb and Yatindra Ranpura. Phil Kermeen followed my talk with his regular AI News and Views feature, before hosting a panel discussion with Manish Patel, Russell Bundy, Stephanie Stasey and me.

I think this might have been our best Bletchley AI event yet! My thanks to everyone involved in organising it, to the other speakers and panellists, and to everyone who attended. I particularly appreciated the conversations and feedback afterwards.

If you’d like to join us at a future event, take a look at UK AI User Groups and Bletchley AI.

I delivered this presentation in a personal capacity. My professional role is vCTO at Node4.

Image credits: Chris Henley/Milton Keynes Tech Week.

Cybersecurity's growing decision-speed gap

markw@markwilson.co.uk (Mark Wilson) — Mon, 2 Nov 2026 00:00:00 +0000

October was National Cybersecurity Awareness Month, and I was recently asked to provide some commentary for Node4 on how AI is changing the cybersecurity landscape, and what businesses should be doing in response.

I’m pleased that some of my comments were picked up by journalists, appearing in articles published by Cybersecurity Insiders and Cyber Protection Magazine.

Those articles brought together perspectives from several contributors, so I thought I’d share my original commentary here, in full. We also posted an edited version as the “CTO Corner” this month’s Node4 customer newsletter.

Cybersecurity’s growing decision-speed gap

National Cybersecurity Awareness Month often focuses on the latest threats, the latest attack techniques and, increasingly, AI. Those things matter, but they’re not the most important lesson businesses should take from what’s happening in cybersecurity today.

The bigger issue is the growing gap between the speed at which attackers can operate and the speed at which many businesses make decisions.

AI is changing the economics, not the fundamentals

AI is changing the economics of cybercrime. It can help attackers automate research, improve phishing campaigns and carry out activities at a scale that once required much more time and expertise. But attacks still tend to rely on weaknesses we’ve understood for years: stolen credentials, excessive privileges, poor visibility, weak governance and slow remediation.

The difference is that attackers can now exploit those weaknesses more efficiently.

Too many businesses still respond through operating models designed for a slower world. Security reviews happen periodically. Access rights are reviewed to a schedule. Vulnerabilities compete with other priorities, while changes move through governance processes before anyone acts. That’s not necessarily a technology problem. In many cases, it’s an organisational one.

The Microsoft Digital Defense Report 2026 (sic) says AI is “compressing attack timelines” and that security teams must prepare for attackers and defenders increasingly operating at machine speed. That supports my view that the cyber gap is becoming a decision-speed gap. The challenge often isn’t spotting the risk – it’s making a decision and doing something about it quickly enough.

Businesses won’t close that gap simply by buying more tools. They need to identify risk, decide what matters and act before an attacker exploits the opportunity.

For most businesses, the priority isn’t a new security programme. Instead, the focus should be on reducing unnecessary privilege, improving visibility, tightening control over identities and shortening the time between identifying a risk and acting on it.

Stop blaming people for poorly designed processes

We also need to stop calling people the weakest link in security.

For years, us IT folks have talked about human error as though employees are a problem to be fixed. But most people are working within processes, systems and incentives that somebody else designed.

If one person can expose sensitive information, approve a fraudulent payment or create a serious incident by clicking a convincing phishing link, we shouldn’t only ask why they made a mistake. We should ask why one human decision was allowed to create that level of risk.

Good security doesn’t assume people will behave perfectly. It assumes mistakes will happen and designs around that reality. Multi-stage approvals, proper segregation of duties, conditional access and stronger control over access and permissions can all reduce the chance of an error and limit the damage when one occurs. That’s more useful than another round of awareness training telling people to be more careful.

Govern AI agents as identities

This becomes even more important as businesses adopt AI agents.

Most organisations are currently thinking about AI agents in terms of productivity and automation. The more important security question is whether they’re treating them as identities.

An agent can access information, use tools and take actions on somebody’s behalf. It may operate across systems that were originally designed around human interaction. That doesn’t automatically make it dangerous, but it does mean the organisation needs to know what it can access, what it’s allowed to do and how those permissions can be changed or removed.

Many businesses already struggle to govern human identities, service accounts and application permissions. Adding AI agents without clear ownership and accountability risks making an existing challenge harder to manage.

For at least a decade, we’ve been talking about identity as the primary control plane for defence and Microsoft now notes that this now extends beyond human users to include applications and agents. Whilst identity-led security isn’t new, what’s changing is the number of non-human identities organisations now need to govern, and the level of autonomy some of those identities may be given.

The question to ask is whether businesses are prepared to apply the same discipline to AI agents that they already know they should be applying to people, applications and service accounts.

Don’t lose sight of the fundamentals

It’s easy to understand why AI dominates so many cybersecurity conversations. The technology is influencing both attack and defence, and its role will only grow over time.

The risk is that businesses become so focused on what AI might change that they overlook the factors that continue to determine whether most attacks succeed.

Identity, governance, resilience and operational discipline aren’t particularly fashionable topics, but they remain the foundations of effective security. AI can help security teams detect threats faster, analyse more data and automate routine activity. Those are valuable capabilities. What it can’t do is compensate for weak processes, unclear ownership or slow decision-making.

This is one area where a good MSP can genuinely help. The challenge is rarely a complete lack of technology. More often it’s a lack of visibility, operational capacity or access to specialist expertise. The value isn’t another security dashboard. It’s helping businesses improve visibility, strengthen governance, access specialist expertise and act more quickly when risks emerge.

The biggest cyber risk facing many businesses isn’t that attackers have suddenly become unstoppable. It’s that attack speed is increasing while decision-making, governance and control remain stubbornly human-paced.

If that gap continues to grow, no amount of security technology will close it on its own.

A PHP security alert and a long-overdue WordPress fix

markw@markwilson.co.uk (Mark Wilson) — Sun, 1 Nov 2026 00:00:00 +0000

A PHP security alert and a long-overdue WordPress fix

I’ve been blogging since 2004. Over that time, my WordPress site has accumulated around 2,500 posts, covering everything from technology and work to cycling, photography and whatever else happened to interest me at the time.

But WordPress had become increasingly unreliable. Intermittent HTTP 503 errors were a recurring frustration, and attempts to upgrade PHP seemed to make matters worse. It was one of the reasons I decided to start afresh with Hugo, a static site generator, at the beginning of 2026.

My new blog uses Hugo, but the old WordPress installation remains online as an archive. Eventually, I’d like to convert those posts to static HTML too, removing the need to maintain WordPress altogether. That’s a project for another day, though.

In the meantime, the old blog still needs to be kept secure. And in October, a PHP security alert gave me a reason to revisit the reliability problems I’d previously worked around rather than resolved.

The problem with keeping old software running

My WordPress installation had been running on PHP 7.4. Not because I thought that was a good idea, but because previous attempts to upgrade PHP had resulted in the site repeatedly exhausting its hosting resources.

The symptoms were frustratingly familiar: intermittent HTTP 503 errors, accompanied by messages suggesting that the server was temporarily too busy to respond.

Rolling back PHP had restored stability, but it wasn’t a satisfactory solution. PHP 7.4 reached end of life in November 2022, so it no longer receives security updates.

Then, in October 2026, the PHP project released security updates addressing critical vulnerabilities, including CVE-2026-109618 and CVE-2026-109619. The PHP 8.4.27 release provided the necessary motivation to try again.

I upgraded to PHP 8.4.27 through cPanel, checked that WordPress and its plugins were up to date, and hoped for the best.

Unfortunately, the 503 errors returned.

Following the evidence

Rather than immediately reverting to PHP 7.4, I decided to investigate properly.

My hosting account has a 1GB physical memory limit. Looking at cPanel’s resource monitoring, it was clear that memory exhaustion, rather than CPU utilisation, was the immediate problem. At one point, I could see 17 concurrent PHP processes associated with WordPress. Individually, they weren’t particularly demanding, but collectively they were putting considerable pressure on the available memory.

My hosting provider had previously suggested Jetpack might be responsible. That’s not an unreasonable suspicion — Jetpack provides a substantial collection of WordPress functionality — but I use several of its features and didn’t particularly want to start disabling things without evidence.

Wordfence was another possibility. Again, it’s a relatively substantial plugin, but there was nothing to suggest that a scheduled malware scan was responsible for the problems I’d observed.

I downloaded the web server access logs and used ChatGPT to help analyse them. They showed substantial automated traffic, including more than 1,800 requests from a crawler called Barkrowler during approximately 14 hours of HTTPS logging.

That’s not necessarily malicious activity. Search engines and other crawlers are part of running a public website, particularly one with more than two decades of content. But every request potentially adds to the load.

And that led me to something rather obvious.

Why wasn’t I caching the pages?

WordPress generates pages dynamically, using PHP and a database. That’s useful when you’re publishing content, managing comments or delivering personalised functionality.

It’s less useful when somebody — or something — requests a blog post from 2010 that hasn’t changed in years. Without effective page caching, WordPress may need to execute PHP and load its plugins each time that page is requested. Multiply that by concurrent visitors and crawlers, and it’s easy to see how a relatively modest hosting account might struggle.

I checked cPanel and discovered that LiteSpeed Cache was already available and enabled at the hosting level. All I needed to do was install the corresponding WordPress plugin and configure it.

I kept things deliberately simple. Public page caching was enabled, but I left object caching, image optimisation and other optional features alone. I also confirmed that LiteSpeed’s built-in crawler was disabled — the last thing I needed was another process systematically requesting thousands of archived pages to warm the cache.

Then I tested the result from my Mac using curl.

The first request returned:

x-litespeed-cache: miss

And the second:

x-litespeed-cache: hit

Success. LiteSpeed had generated and cached the page on the first request, then served the cached version on the second.

That means subsequent requests for the same public page can be handled without running WordPress again.

A week without a crash

At the time of writing, it’s been just over a week since I enabled LiteSpeed Cache, and I haven’t seen another 503 error.

That’s a considerable improvement on the previous situation, when the site was repeatedly exhausting its hosting resources. I can’t claim to have conclusively diagnosed every aspect of the original problem, but the evidence strongly suggests that repeated requests to uncached WordPress pages were a significant contributor.

More importantly, I’ve been able to keep PHP 8.4.27, Jetpack and Wordfence running without increasing my hosting resources or sacrificing useful functionality.

For now, I’m leaving the configuration alone. If the errors return, there are other avenues to investigate, including aggressive crawler traffic and PHP worker concurrency. But after more than a week of stability, I’m reasonably confident that caching has made a substantial difference.

A reminder about technical debt

There’s a broader lesson here about maintaining older systems.

My WordPress blog isn’t a business-critical application, but it’s still a public-facing service that needs security updates, dependencies and hosting resources. Leaving it on an unsupported PHP version wasn’t a sustainable answer, even if it appeared to make the immediate problem disappear.

Moving my new content to Hugo reduced my dependence on WordPress, but it didn’t eliminate the technical debt associated with maintaining the old archive. The security alert forced me to revisit an issue I’d worked around rather than resolved.

In the end, the improvement didn’t require more memory, a hosting migration or removing useful functionality. It came from recognising that most requests to a long-established blog shouldn’t need to execute the entire WordPress application.

Eventually, I’ll finish moving the archive to static HTML and remove that dependency altogether.

Until then, a little caching seems to have bought me some breathing space.

Adding my Somfy garage door to Home Assistant

markw@markwilson.co.uk (Mark Wilson) — Fri, 30 Oct 2026 00:00:00 +0000

I’ve been gradually connecting more devices to Home Assistant, and my garage door was next on the list.

It’s a roller shutter door controlled by a Somfy Rollixo RTS. The existing radio remotes work perfectly well, but I wanted to operate it from Home Assistant without replacing the controller or adding another proprietary hub.

After discussing the options with ChatGPT, I settled on a SONOFF MINI-ZBD. It’s a small Zigbee relay with volt-free (dry) contacts, which makes it suitable for connecting to the Somfy’s external keyswitch input.

Wiring it up

The Rollixo RTS has a keyswitch input that operates the door when two terminals are briefly connected. The MINI-ZBD can provide that connection through its normally open relay. Better still, the Somfy has a 24V DC auxiliary supply, so there’s no need for a separate power adapter.

For my Rollixo RTS, I used these connections:

Somfy terminal	SONOFF connection	Purpose
14 (+24V DC)	DC+	Power
15 (0V)	DC−	Power
10 (keyswitch)	NO	Relay contact
11 (keyswitch)	COM	Relay contact

The relay simply closes the keyswitch circuit. It doesn’t introduce any voltage to those terminals.

I isolated the controller from the mains before making the connections. If you’re doing something similar, check the terminal assignments for your particular controller.

The MINI-ZBD is small enough that I was able to mount it inside the existing Somfy Rollixo housing, keeping everything neatly contained rather than having another box mounted alongside it.

Adding it to Home Assistant

My setup uses a Home Assistant Green with a Connect ZBT-1 Zigbee adapter (originally called SkyConnect), running Zigbee Home Automation (ZHA).

Pairing the MINI-ZBD was straightforward. Home Assistant discovered it as a switch, which I named Garage Door Controller and assigned to the Garage area.

Switching the relay on and off operated the door, but there was a catch. The Somfy expects a momentary contact, like pressing and releasing a button. The MINI-ZBD, however, appears in ZHA as an ordinary on/off switch. Once switched on, it stays on. SONOFF calls the momentary function inching. Although the MINI-ZBD supports it, the option isn’t currently exposed through my ZHA installation. It is available through Zigbee2MQTT, but I didn’t want to change my Zigbee setup just for one device.

With some guidance from ChatGPT, I created a simple Home Assistant script instead:

alias: Garage Door Trigger
mode: single
sequence:
 - action: switch.turn_on
 target:
 entity_id: switch.garage_roller_shutter_door_controller
 - delay:
 milliseconds: 500
 - action: switch.turn_off
 target:
 entity_id: switch.garage_roller_shutter_door_controller

This switches the relay on for half a second, then switches it off again. Testing confirmed that the Somfy responds just as it does to the original remote control.

There is an important limitation. This is a software-controlled pulse, not hardware-enforced inching. If the second command fails, the relay could remain energised. For a motorised door, hardware-enforced momentary operation would be preferable.

Tidying up the dashboard

I didn’t want the underlying SONOFF switch appearing on my Home Assistant dashboards, where it could accidentally be left on. Fortunately, Home Assistant lets you hide an entity without disabling it. In the switch’s settings, I turned Visible off but left Enabled on. I then assigned the Garage Door Trigger script to the Garage area. That gives me a simple way to activate the door without exposing the underlying switch.

I also have an IKEA PARASOLL Zigbee contact sensor on the garage door, so Home Assistant can tell whether it’s open or closed. I’ve used that to create automations that turn the garage light on and off according to the door’s position.

That means Home Assistant can now operate the door, report its status and control the garage lighting, all through Zigbee.

A familiar Somfy problem

While working on the integration, I also encountered an old problem with the Somfy’s wireless safety-edge transmitter. The door would stop part-way down, just as it did when I wrote about the problem back in 2016.

Once again, the battery was the culprit. I had a spare Tadiran SL-760 3.6V lithium AA battery, but although it measured 3.56V on a multimeter, it didn’t resolve the issue. On closer inspection, it was marked May 2018, so it had been sitting around for more than eight years.

I replaced it with a new Saft LS14500, also a 3.6V lithium AA battery, but with a slightly higher nominal capacity (2600mAh compared with the Tadiran’s 2200mAh). That did the trick. Whether the difference was down to the battery’s age or its electrical characteristics under load, I can’t say. But the safety edge is behaving again.

What’s next?

The MINI-ZBD is a neat way to connect an existing garage door controller to Home Assistant. It uses the Somfy’s own power supply, works over Zigbee and leaves the original radio controls intact.

The only disappointment is the lack of hardware inching support through ZHA. I’ll revisit that when support becomes available. For now, I’ve brought another part of the house into Home Assistant without introducing another hub or cloud dependency.

Beyond the AI hype at DTX+UCX London 2026

markw@markwilson.co.uk (Mark Wilson) — Thu, 15 Oct 2026 00:00:00 +0100

I missed the first day of DTX+UCX London this year, but managed to carve out some time to attend the second.

Unsurprisingly, AI was everywhere. Agents, models, copilots and AI-powered features in seemingly every contact centre, networking and cybersecurity management platform. I’m not suggesting these developments aren’t important, but after a while the messages start to sound remarkably similar.

Fortunately, there were some sessions that explored rather more interesting questions. Not so much what AI can do, but how we adopt it, what it means for people, and whether we’re making sensible decisions about the technology we depend on.

Here are some of my highlights from the day.

Preparing for a TUNA world

Lord Toby Harris, Chair of the National Preparedness Commission, delivered an excellent opening keynote on resilience and recovery. No slides, just a speaker who knew his subject and could hold an audience’s attention.

The National Preparedness Commission was conceived before COVID-19 and has since published around 50 papers examining how the UK can become better prepared for the risks it faces.

Lord Harris described the world we live in as TUNA:

Turbulent
Uncertain
Novel
Ambiguous

It’s an environment in which preventing disruption isn’t always possible. We also need to think about mitigating the consequences and recovering when things go wrong. He illustrated this with examples of how dependent our everyday lives have become on interconnected infrastructure.

A power failure doesn’t just turn off the lights. It affects telecommunications, transport, water supplies, petrol stations, cash machines and payment systems. Emergency generators might keep essential services running, but only if they’ve been maintained, tested and have sufficient fuel. And even if a hospital has power, can its staff get to work?

The dependencies extend far beyond electricity. Water needs pumping, energy infrastructure needs cooling, food distribution relies on transport, and transport increasingly relies on digital systems.

These are not independent systems. They’re part of a complex web of dependencies, where a failure in one place can have consequences elsewhere.

When the threat isn’t directed at you

An organisation doesn’t need to be the intended target of an attack to suffer the consequences. The recent cyber incidents affecting M&S, Co-op and Jaguar Land Rover have demonstrated how disruption can spread through supply chains. Geopolitical instability creates further risks, particularly where organisations depend on imported materials, components and services.

Lord Harris also raised questions about sovereign capability. How much control do we really have over the infrastructure and services on which our economy depends? That question became particularly relevant during the Q&A, when the discussion turned to AI.

We’re already seeing opposition to data centre developments because of their electricity and water requirements. Meanwhile, we’re increasingly dependent on technology developed and controlled by organisations outside the UK. There’s a balance to be struck between accessing the best available technology and retaining sufficient control over critical national capabilities.

This is a question I’ve been exploring in my own presentations on sovereign AI. Sovereignty isn’t simply about where data is stored or processed. It’s about understanding who controls the technology, what dependencies exist, and what options remain if those relationships change.

Preparing for failure

For organisations, Lord Harris’ advice was to identify their “crown jewels”: the systems, information and capabilities they absolutely depend on.

Then ask what happens when those things aren’t available.

What if your systems are functioning but your suppliers aren’t? What if your employees can’t travel? What if the telecommunications network is unavailable? It’s not enough to have a disaster recovery plan that assumes everything else is working.

Resilience also requires a whole-society approach. Government, businesses, communities and individuals all have responsibilities.

Lord Harris closed with Baden-Powell’s Scout motto from 1908: Be Prepared.

That seems as relevant today as it was in the early 20th Century.

Building AI confidence by giving people permission to play

Julie Creffield, from Oxford Innovation Space, took a very different approach to AI adoption.

She started by asking who in the audience felt completely on top of AI. It’s rather like asking whether people fully understood the Internet in the 1990s. We’re still learning what this technology can do and how it will change our lives. Her central message was that building confidence starts with giving people permission to play.

That might sound obvious, but organisations often approach AI adoption through formal training programmes, policies and productivity targets. We tell people they need to use AI, without necessarily giving them the time or freedom to experiment.

Julie challenged the language we use to describe technology adoption, particularly the familiar labels of early adopters and laggards. Instead, she suggested thinking about people as sceptics, experimenters, integrators, experts and architects. These descriptions are less judgemental and recognise that people approach new technology from different starting points.

Finding opportunities in everyday work

One of the most practical ideas from Julie’s session was her approach to identifying AI use cases through three categories:

Icks: The tasks you dislike, find draining or spend too much time doing. Repetitive administration, managing email, searching for information and preparing reports.
Slicks: The things you’re good at and want to spend more time doing. Creative thinking, problem-solving, building relationships and strategic planning.
Triggers: Recurring situations that create work, pressure or disruption. A new project, an approaching deadline, an unexpected request or a change in priorities.

The idea is to use AI to reduce the effort spent on the “icks”, create more space for the “slicks”, and help manage the “triggers”.

It’s a useful way to approach AI adoption without starting with the technology itself.

Julie also shared a simple prompting framework called THINK:

Task: What am I trying to achieve?
Human: Who is the AI helping, and what role should it play?
Instructions: How should it behave and respond?
kNowledge: What information and context does it need?
Keep improving: How will I test and refine the results?

The slightly unconventional use of N for Knowledge was deliberate: a reminder that AI can invent information when it doesn’t know the answer.

There’s nothing especially complicated about any of this. That’s rather the point. Building confidence doesn’t necessarily require a sophisticated technical understanding of AI. It requires opportunities to experiment, learn and improve.

Successful change is about people, not technology

Viola de Girolami’s session, The Anatomy of Successful Change, explored why some organisations manage transformation successfully while others struggle.

She structured her presentation around four characteristics: clarity, empathy, a learning mindset and momentum.

Clarity: knowing which mountain you’re climbing

Viola used McDonald’s response to changing customer expectations as an example of an organisation recognising that it needed to evolve.

The important question wasn’t simply what products or services it should introduce, but what kind of organisation it needed to become to remain relevant. The same principle applies to AI.

Viola described AI as a good pair of walking boots. They might help you climb the mountain, but you still need to know which mountain you’re trying to climb.

Too many organisations seem to be starting with the technology and then searching for a problem to solve. Without clarity about the intended outcome, it’s difficult to know whether an investment has been successful.

Empathy: understanding what people fear losing

Another point was that we’re not leading digital transformations. We’re leading human transitions.

People don’t necessarily resist change itself. They resist what they fear losing. That might be familiarity, status, confidence, a sense of belonging or the value they believe they bring to their organisation.

It’s easy to overlook these concerns when discussing transformation in terms of technology platforms, operating models and efficiency targets. But successful change requires us to understand how people experience it, not simply explain why it’s necessary.

Learning: challenging comfortable assumptions

Viola compared our assumptions to a favourite old jumper. It might be worn out, but it’s familiar and comfortable. Organisations develop similar attachments to established ways of thinking.

We need to distinguish between what we know, what we believe and what we’ve simply assumed to be true. That’s particularly important when technology and customer expectations are changing quickly.

Momentum: responding to changing conditions

Finally, Viola talked about the importance of recognising signals from the outside world and adapting accordingly. A strategy shouldn’t become something we follow regardless of changing circumstances.

Her question was a useful one:

“If you were starting today, would your strategy look the same?”

It’s worth asking periodically, particularly when AI is changing both what’s possible and what customers expect.

Nobody gets fired for accepting the defaults

Dan Jones, from Hamina, provided a welcome change of subject with a session about Wi-Fi configuration.

His title referenced the old saying that nobody ever got fired for buying IBM, or Cisco in the networking world. His variation was that nobody gets fired for accepting the defaults. (Except that’s exactly what we’ve spent years telling people not to do in cybersecurity!)

Dan’s argument was that default configurations are typically designed to provide a good initial experience. They aren’t necessarily optimised for the environment in which a system will operate.

He used the example of an office with 28 wireless access points, configured automatically with 80MHz channels. Everything looked fine in the management console, yet users experienced intermittent performance problems. The problem wasn’t necessarily faulty equipment or a broken configuration. It was that the settings weren’t appropriate for the radio environment. Reducing channel widths to 40MHz improved reliability, even though the theoretical maximum speed was lower.

Dan also highlighted that the environment changes. Neighbouring networks, devices and interference can all affect wireless performance. A decision made when an access point starts up may no longer be appropriate later.

The wider lesson wasn’t really about Wi-Fi.

“A default is a decision somebody else made, for somebody else’s requirements.”

We should be able to explain why a system is configured in a particular way, rather than accepting the defaults without question. That applies to performance, reliability and security alike.

Making sense of the EU AI Act

Kevin Lavin from Citi and Jamal Ahmed from Lumi discussed the EU AI Act, drawing on Jamal’s book, “The Easy Peasy Guide to the EU AI Act”, which aims to make the legislation accessible to people without a legal background.

Much of the commentary on AI regulation is written by lawyers for lawyers. The challenge is to simplify complex requirements without losing the important detail.

For UK organisations, there’s also a common misconception that European regulation no longer matters following Brexit. However, the EU AI Act has extraterritorial reach. Depending on how an organisation develops, supplies or uses AI systems, it may have obligations even if it isn’t established in the EU.

The legislation takes a risk-based approach, with different requirements depending on the potential impact of an AI system. Some uses are prohibited. Others, particularly those that could affect people’s safety or fundamental rights, face more extensive obligations. There are also transparency requirements for certain systems and relatively limited obligations for minimal-risk applications.

Importantly, responsibilities don’t fall solely on the organisations developing AI systems. Businesses deploying them may also have obligations.

You can’t govern what you don’t know about

Perhaps the most practical point was the importance of understanding what AI is already being used across an organisation. Shadow AI makes this difficult. Employees may be using AI services to help with everyday tasks without their employer knowing which tools are involved or what information is being shared.

Simply banning AI isn’t necessarily the answer. It can encourage people to find alternative ways to access the tools they believe they need. Instead, organisations need visibility, clear accountability and an understanding of the risks associated with individual use cases.

The discussion also touched on agentic AI, where systems can take actions rather than simply generate responses. This introduces further questions about identity, permissions, accountability and control.

AI governance can’t be treated as a one-off IT compliance exercise. The technology, its uses and the associated risks continue to evolve.

Are we developing the workforce we’ll need tomorrow?

One of the most interesting discussions for me came from the panel on the future workforce, featuring Steven Fuller, Claire Lebarz, Sunita Nicholas and Phil Benson.

The discussion explored how AI is changing work, the skills organisations need and the consequences for career development.

Claire suggested that AI adoption is perhaps 20% a technology challenge and 80% a people and organisational challenge. The exact percentages matter less than the underlying point. Technology is only one part of the equation.

What happens when we automate the learning opportunities?

A particularly interesting concern for me (as a parent of two sons in their 20s) was the effect of AI on junior roles.

Many experienced professionals developed their judgement by doing relatively routine work early in their careers. They made mistakes, learned from colleagues and gradually developed an understanding of context and consequences.

If AI now performs much of that work, how will the next generation gain equivalent experience?

Phil made the point that AI hasn’t necessarily removed the junior job. In some cases, it has effectively promoted people without giving them the training and experience that would traditionally come first. There were different views about whether AI is already reducing entry-level opportunities. Claire suggested that the wider economic environment was a more significant factor than AI itself. But there was broad agreement that organisations need to rethink how people learn.

Productivity isn’t the same as capability

Another theme was the difference between producing more work and developing a more capable workforce. AI can help people complete tasks more quickly, but that doesn’t automatically mean they’re developing the understanding needed to challenge the results. This is particularly important when AI produces something that looks convincing but is incomplete, incorrect or inappropriate.

Domain expertise, critical thinking and professional judgement remain essential.

The panel also discussed mentoring, psychological safety and the importance of giving people opportunities to ask questions and admit mistakes. Remote and distributed working can make some of these things harder, particularly when junior colleagues have fewer opportunities to learn informally from more experienced people.

People are more than their current job descriptions

As AI changes the nature of work, some roles will evolve significantly. That creates challenges for organisations trying to retain experienced employees whose skills and professional identities have developed around particular activities.

Claire argued for a more skills-oriented approach, recognising people’s strengths and helping them move between roles. The discussion also touched on workload, burnout and the pressure to keep adapting. Organisations need to create environments where people can learn and change without feeling that they must constantly work harder to keep up.

Steven closed with a question that captured the discussion well:

“Are we building a workforce that can deliver today, and tomorrow?”

Do we actually need an AI agent?

The final session I attended explored trust in agentic AI, with a panel discussing what happens when agents behave in unexpected ways. The conversation returned to familiar questions about guardrails, permissions and accountability, but there were a couple of points worth retaining.

The first was whether an agent is actually necessary. There’s considerable pressure to adopt agentic AI, but not every problem requires an autonomous system. Sometimes a conventional application, workflow or automation would be more appropriate.

The second was the importance of understanding what an agent is authorised to do. An agent acting within its permissions might still produce an undesirable outcome. That raises questions about whether the problem lies with the agent, its instructions or the permissions it was given.

As with any other technology, security needs to be considered from the outset rather than added afterwards. Human accountability doesn’t disappear simply because software is making decisions or taking actions on our behalf.

Beyond the technology

Looking back over the day, I found the sessions that moved beyond AI features and product capabilities the most useful.

Perhaps that’s because, after several years of increasingly ambitious AI announcements, I’m less interested in hearing what the technology might be capable of and more interested in understanding how organisations are actually going to make it work.

How do we build confidence without losing control? How do we introduce new capabilities without creating dependencies we don’t understand? And how do we improve productivity without undermining the development of the people we’ll need in future?

I don’t expect a technology conference to answer all those questions. But I’m glad that some of the speakers were asking them.

Which Mr M Wilson?

markw@markwilson.co.uk (Mark Wilson) — Mon, 24 Aug 2026 00:00:00 +0100

Which Mr M Wilson?

Why is Barclaycard sending me a PIN for a credit card I don’t recognise?

That was the slightly alarming question I found myself asking recently.

The envelope was addressed to “Mr M Wilson” at my home address. That’s me, so I opened it. Inside was correspondence about a PIN for a credit card. I do have a Barclaycard, but I don’t often use it.

After attempting to use this information to change the PIN on my card, and then spending rather more time than I would have liked navigating Barclaycard’s automated telephone system, I eventually worked out what had happened.

The letter wasn’t for me at all. It was for my son.

Similar, but not identical, names

I’m Mark. And one of my adult sons, Matthew, lives at the same address. So we’re both Mr M Wilson.

We both have middle names too, so even using our full initials would distinguish between us.

Yet Barclaycard, along with several other organisations, insists on addressing correspondence using only our title, first initial and surname. Often, inside the envelope, they write something like “Dear Mark” — although not in this case.

Most of the time, that’s just an irritation. One of us opens a letter, starts reading and realises that it belongs to the other. This time, seeing something financial that I didn’t recognise was enough to make me wonder whether there was a problem with an account in my name.

All because the envelope didn’t contain enough information to tell two people at the same address apart.

Why just an initial?

Perhaps it’s about privacy. An initial reveals less than a full first name, so at first glance that might seem consistent with the principle of data minimisation.

But data minimisation doesn’t simply mean using as little information as possible.

The Information Commissioner’s Office says personal data should be “adequate, relevant and limited to what is necessary”. It describes adequate as having enough information to properly fulfil the intended purpose.

The ICO’s guidance on identifiers also notes that, where a name isn’t enough to distinguish between two people, further details may be needed.

The purpose of putting a name on an envelope is surely to identify the intended recipient. At our address, Mr M Wilson doesn’t do that.

And Barclaycard has the information it needs. Emails address me as “Hello Mark”. Somewhere between my customer record and the envelope, Mark becomes M.

Printing “Mark” or “Matthew” instead of “M” would reveal a few additional letters about us to somebody looking at our mail. But not printing them resulted in me opening correspondence about my son’s credit card.

If privacy is the reason for using an initial, that seems a curious outcome.

I tried to ask

Rather than speculate about why Barclaycard addresses its correspondence this way, I thought I’d ask.

After my earlier experience with the telephone system, I tried the messaging service in the Barclaycard app.

Unfortunately, having invited me to “Send us a message”, the app told me that messaging was unavailable and suggested I call instead. You couldn’t make it up…

So I still don’t know why Barclaycard uses only an initial. And, to be fair, it’s not the only organisation that does.

There’s nothing particularly unusual about two adults with the same surname and first initial living at the same address. Nor am I suggesting that putting Mr M Wilson on an envelope is a breach of data protection law.

Most of the time, the only consequence is that one of us opens the other’s post. Occasionally, though, it’s a worrying time wondering why you have been issued a PIN for a credit card you don’t recognise.

I’d happily trade a few more letters on the outside of the envelope to avoid finding out what’s on the inside of someone else’s.

The unintended consequences of good security

markw@markwilson.co.uk (Mark Wilson) — Fri, 21 Aug 2026 00:00:00 +0100

The unintended consequences of good security

My bag felt light yesterday morning. I didn’t think much of it until I got to the station and realised why: my laptop was still at home.

For a moment, I considered going back. Twenty minutes home, a couple of minutes to grab it, then perhaps another thirty to get back to the station. I’d lose an hour, possibly my parking space and maybe another train. Everything would be getting tight for my first meeting.

So I decided to chance it.

Maybe I don’t need a laptop

Actually, most of my day would be fine. I had my work phone for a Teams call and could take notes on that too. The RFP response I needed to review would have to wait until I got home, and I’d need to work into the evening, but that wasn’t the end of the world. In some ways, it was a nice demonstration of how much less dependent we’ve become on a particular device.

Then I remembered the presentation.

The deck was in OneDrive and I’d sent a link to my team the day before. I could open it on my work phone, but that wasn’t much use for presenting to a room — I couldn’t access my notes at the same time. I had my personal iPhone and iPad with me, though. Surely I could just open the presentation in a browser on one of those?

No. And, to be fair, that’s exactly what our information protection controls are there to prevent. The presentation was classified Internal and my personal devices are unmanaged. I wasn’t trying to download it or keep a copy; I just wanted to open it in a browser long enough to put it on a meeting-room screen.

There must be another way

So I did what people do when technology gets in the way: I started looking for an alternative approach. At that moment I wasn’t thinking like a technology leader, considering information classification, device management and acceptable risk. I was just a user, trying to get stuff done.

Could I get the link onto another device? Could I open it differently? Could I ask a colleague to present it for me? Eventually, I presented from a colleague’s laptop. Problem solved, and without moving the information somewhere it shouldn’t be.

But it left me thinking about the friction we introduce in the name of security. We might understand all the individual layers and controls we’ve put in place, but our users don’t experience them individually. They experience the cumulative friction when something they need to do doesn’t work.

And their need to get stuff done doesn’t disappear.

Friction changes behaviour

That’s the bit I think we sometimes miss. When we introduce a security control, we quite rightly think about the behaviour we want to prevent. I would argue that we should spend some time thinking about the behaviour the control might create too.

I needed to present that deck, so when one route was closed I looked for another. I found an approved route, but make legitimate work difficult enough and people will inevitably find other ways to get it done. That’s not necessarily because they’re malicious or careless. Sometimes they’re just users with a meeting starting in ten minutes.

That makes security friction more than a user-experience problem. A control can reduce one risk while inadvertently encouraging behaviours that create another.

I’ve seen this before. One organisation I worked for introduced a multilayered information classification scheme intended to help people protect information appropriately. The choices were complicated enough that some users responded by marking almost everything as unclassified. A policy designed to improve information protection had inadvertently encouraged people to do the opposite. Not because they didn’t care about security, but because the secure way of working had become too difficult.

There isn’t an easy answer to this. Removing the controls isn’t it, but neither is assuming that tighter controls are always better controls.

Somewhere between information protection and getting the job done is a judgement about acceptable risk. When we’re making that judgement, we need to consider not only what a control prevents, but what it encourages people to do instead.

13 Minutes…

markw@markwilson.co.uk (Mark Wilson) — Thu, 13 Aug 2026 00:00:00 +0100

13 Minutes…

In 2018, I fulfilled a lifelong dream.

On a family holiday to Florida and Maryland, we spent a day at the Kennedy Space Center. I stood underneath a Saturn V, saw the Space Shuttle Atlantis and got to see artefacts from the history of American space exploration. These were the very same things that I’d read about as a child and dreamed of seeing for almost forty years.

I grew up in the 1970s and 80s, when space travel still seemed to be part of the future. I wasn’t a space geek, but the books in the school library certainly left an impression. Apollo missions, enormous rockets, astronauts walking on the Moon and visions of people living on space stations – or even on the Moon itself. The year 2000 was the future then, and it was all incredibly exciting.

Then came the Space Shuttle.

For my generation, the Shuttle was the spacecraft. It looked more like an aeroplane than a rocket and seemed to promise that travelling into space might one day become almost routine. Of course, we know it didn’t quite work out that way.

Recently, I’ve been revisiting some of that history through the BBC World Service podcast 13 Minutes to the Moon.

The first series tells the story behind the final 13 minutes of the Apollo 11 descent. I loved the drama of it. We all know how the story ends, but the storytelling puts you right back into those moments – the alarms, the decisions and the dwindling fuel supply. I couldn’t wait for the next episode to be released.

Series two does something similar with Apollo 13, another story where knowing the outcome does nothing to diminish the tension.

Somehow, series three passed me by completely. So, when I recently noticed that it had appeared in my podcast feed, I was delighted to discover there was more 13 Minutes… waiting for me. This time the subject was the Space Shuttle. It’s a different kind of story, covering an entire programme rather than a single mission, but I found it fascinating and binge-listened to the whole series.

And now I’m catching up with series four.

This one is different again. Rather than looking back and retelling a story, it follows Artemis II day-by-day – the April 2026 mission that took humans around the Moon for the first time since Apollo 17 in 1972.

Perhaps we didn’t end up living in space as I imagined we might when I was a child. But, more than 50 years after Apollo, humans are travelling beyond low Earth orbit and around the Moon again.

And 13 Minutes… has taken me right back to those books in the school library.

If any of that captures your imagination too, it’s well worth starting at the beginning.

Listen to 13 Minutes to the Moon on BBC Sounds.

Bring your own network

markw@markwilson.co.uk (Mark Wilson) — Wed, 5 Aug 2026 00:00:00 +0100

Bring your own network

Most of us have heard of bring your own device. We expect our laptops, phones and tablets to work wherever we are.

But what if, instead of trusting somebody else’s network, you could simply take your own with you? That was the idea behind one of my more recent impulse purchases: the UniFi Travel Router (UTR).

It doesn’t look particularly special. It’s a small white box that slips easily into a laptop bag. It isn’t even self-powered, so you’ll need a USB-C cable and a power source. That feels like an odd omission for something designed for travel.

After using it on a few trips, though, I realised it wasn’t really a travel router. It was a way to carry my home network with me—making public Wi-Fi safer, simpler and, in some cases, almost invisible.

It’s now one of the gadgets that lives permanently in my laptop bag.

The problem with public Wi-Fi

Whether you’re in a hotel, airport lounge, coffee shop, conference venue or on a train, public Wi-Fi is often the easiest way to get online.

Modern websites encrypt almost everything using HTTPS, so this isn’t as risky as it once was. Even so, you’re still placing your trust in someone else’s network. You don’t know how it has been configured, who else is connected, or whether there’s a convincing rogue hotspot using a similar name.

I’d rather not have to think about any of that. Instead, I’d rather treat every unfamiliar network as simply a way of reaching one that I already trust.

One network, everywhere

Here’s how it works:

Instead of connecting each of your devices directly to the local Wi-Fi, you connect the travel router.
Using the UniFi app on your phone, you tell the travel router which local Wi-Fi network to join. If there’s a captive portal, such as the familiar hotel “accept our terms” page, you complete that authentication once from your phone.
The router then establishes a secure UniFi Teleport VPN connection back to your home network. From that point on, every device connected to the router behaves as though it’s sitting in your house.

Your traffic is encrypted between the travel router and your home, so, in effect, you’ve taken your home network with you.

Many guest Wi-Fi networks require you to authenticate each device individually through a captive portal. Some even limit the number of devices you can connect.

With the travel router, I authenticate once using my phone. After that, every other device simply connects to my own Wi-Fi network, exactly as it does at home.

My laptop, phone and tablet don’t know they’re connected to a guest network. As far as they’re concerned, they’re connected to the same network they always use.

To the venue, it looks like a single connected device. Behind the travel router, I can connect as many of my own devices as I like.

More than just security

I bought the travel router because I liked the idea of taking a trusted network with me. And, if I’m honest, because I’m a bit of a geek.

In practice, convenience has become the bigger benefit.

Everything behaves exactly as it does at home. My devices reconnect automatically, local services continue to work, and I don’t spend the first ten minutes in every hotel room joining Wi-Fi networks and accepting terms and conditions.

Websites should also see my home IP address rather than the IP address of the network I’m connected to. Although I haven’t travelled abroad with the UTR yet to test this, services that are normally only available in the UK should continue to work without needing a separate VPN subscription.

I’m simply using my own internet connection, wherever I happen to be.

It’s not perfect

The lack of an internal battery means you need to remember a USB-C power source. In practice, I’ve just plugged mine into the same charger that powers my phone overnight, but it would have been nice to have an hour or two of battery life for situations like trains or airport lounges.

It also assumes you already have a UniFi gateway at home capable of running Teleport. I do, but if you don’t, this probably isn’t the travel router for you.

Bringing your own network

I’ve written before that the best technology quietly disappears into the background.

The UniFi Travel Router does exactly that.

Every time I travel, it removes a little friction. I authenticate to guest Wi-Fi once, my devices reconnect automatically, and I know my traffic is heading back through a network that I already know and trust.

I can’t see myself travelling without it now.

Mark's Thoughts

A little more thought, please

A little more thought, please

The language of warfare

Salespeople who haven’t done their homework

Cold emails, and the inevitable follow-ups

Don’t put things in my calendar

AI-generated presentations that all look the same

And yes, I used AI to help write this

Show some consideration

Sovereign AI: preserving choice in an intelligent world

Sovereign AI: preserving choice in an intelligent world

From road atlases to artificial intelligence

AI is becoming infrastructure

Sovereignty is about more than location

Moving beyond sovereignty claims

Not everything needs maximum sovereignty

Keeping our options open

PostScript

Cybersecurity's growing decision-speed gap

Cybersecurity’s growing decision-speed gap

AI is changing the economics, not the fundamentals

Stop blaming people for poorly designed processes

Govern AI agents as identities

Don’t lose sight of the fundamentals

A PHP security alert and a long-overdue WordPress fix

A PHP security alert and a long-overdue WordPress fix

The problem with keeping old software running

Following the evidence

Why wasn’t I caching the pages?

A week without a crash

A reminder about technical debt

Adding my Somfy garage door to Home Assistant

Wiring it up

Adding it to Home Assistant

Tidying up the dashboard

A familiar Somfy problem

What’s next?

Beyond the AI hype at DTX+UCX London 2026

Preparing for a TUNA world

When the threat isn’t directed at you

Preparing for failure

Building AI confidence by giving people permission to play

Finding opportunities in everyday work

Successful change is about people, not technology

Clarity: knowing which mountain you’re climbing

Empathy: understanding what people fear losing

Learning: challenging comfortable assumptions

Momentum: responding to changing conditions

Nobody gets fired for accepting the defaults

Making sense of the EU AI Act

You can’t govern what you don’t know about

Are we developing the workforce we’ll need tomorrow?

What happens when we automate the learning opportunities?

Productivity isn’t the same as capability

People are more than their current job descriptions

Do we actually need an AI agent?

Beyond the technology

Which Mr M Wilson?

Which Mr M Wilson?

Similar, but not identical, names

Why just an initial?

I tried to ask

The unintended consequences of good security

The unintended consequences of good security

Maybe I don’t need a laptop

There must be another way

Friction changes behaviour

13 Minutes…

13 Minutes…

Bring your own network

Bring your own network

The problem with public Wi-Fi

One network, everywhere

One login, all your devices

More than just security

It’s not perfect

Bringing your own network