Skip to main content

The future of Technology Assurance in the UK

Chris Ensor highlights some important elements of the NCSC's new Technology Assurance strategy.

This content was last reviewed on 05/03/2025

The NCSC, and CESG before it, has been involved in assuring the security of technology for well over 30 years. In that time, our assurance work has expanded, in tandem with the growing role of technology in all our lives.

Today we are publishing a White Paper which summarises our thinking on where assurance should go next. The paper outlines a new approach to gaining confidence in the cyber security of technologies on which the UK relies.

Helen's blog post does a great job of illuminating our new Principle-based approach. So, in this post, I want to set the scene with a bit of history, and highlight a few of the most important take-aways from the white paper.

Once upon a time

We started by assuring devices used to protect the most sensitive data in Government. Then, in the '90s our work expanded to include devices that were aimed at protecting less sensitive government (and sometimes commercial) information. In the last few years it’s stretched even further, to include assessing the security functionality of devices with more practical everyday uses, such as smart meters.

Today we don't consider security functionality in isolation, as in reality, any device or piece of software has a role to play in cyber security. If it’s not built and maintained properly it can have vulnerabilities that offer an open door for an attacker.

Gaining confidence

We have also been deeply involved in the standards and methodologies used to gain confidence in the security of a device.

In the '80s CESG operated the UK IT Security Evaluation and Certification Scheme. In the late '80s we worked with colleagues in France, Germany, and the Netherlands to create the IT Security Evaluation Criteria (ITSEC) - a European-wide approach to security product evaluation and mutual recognition.

Then, in the mid-90s we worked with colleagues in Canada, France, Germany, the Netherlands, and the U.S. to develop an international approach, through the Common Criteria scheme.

Whilst all this international work was going on, we continued to develop national approaches to meet national challenges. Commercial Product Assurance was a good example of that.

Current thinking

We've done a lot of thinking, lately, about the direction technology assurance needs to take. The white paper gives a thorough introduction to our plans, so here I just want to draw out some important aspects of the thinking behind those plans.

It’s not just about the security

Well, it is, but what I mean is that it’s not just about the functionality of a security product, like firewalls or VPNs. We must include devices and software whose primary function is not security, but contain security functionality (like a car).

It’s going to be more important than ever that technology in general use won’t make your organisation - or your home - vulnerable to attack because of poor design, implementation, or maintenance. Our approach to technology assurance must be able to cater for all these different cases.

We’re not alone

Whilst our primary aim is to raise the cyber security bar in the UK, we have to recognise that other nations and organisations want to do the same thing and there are other schemes and approaches out there that vendors will need to engage with.

Our strategy will need to consider these approaches and ensure we have means of gaining equivalency where appropriate.

How secure does it need to be?

Cyber security is all about managing risks and those are going to be different depending on the environment.

If you’re dealing with highly sensitive data, you want to be able to find technology that will protect you against the most sophisticated tools and techniques. But, for the majority, it’s about using technology that is good enough to resist things that are publicly available. Cyber Essentials calls these “commodity capabilities.”

If we come up with an approach that tries to make all technology resilient against the former then timescales will extend, costs will rocket, and choice will vanish. We need to be able to cater for the variety of risk environments in which people operate and provide the information that will allow them to identify resilient technologies that meet their needs.

How prescriptive should we be?

If I were to describe existing approaches to product assurance in one word, it would be “prescriptive”. Focusing on the details of how requirements for certification should be met doesn’t leave a lot of room for innovation - an essential component of a healthy cyber security environment. It also requires a lot of effort to produce and maintain the standards involved, so they reflect changes in technologies.

This approach does have some benefits in that vendors have a clear understanding of what they need to do to meet the requirements and it’s easier for products to be assessed against them. This, perhaps, reduces the level of skills needed to make judgements and interpret instructions.

After successfully piloting the principles approach using the test case of cross domain solutions, we are confident that principles developed by the NCSC can be used to gain confidence in the security of a very wide range of technologies.

Secure by Design

Time and again, the root cause of a successful cyber attack on an organisation (or individual) is a vulnerability in a technology they are using.

OK, it may be because they haven’t applied a patch, but reducing the need for patches in the first place starts to address that root cause. We know many product developers have done a lot of hard work to improve their engineering practices, but it’s certainly not consistent across the board.

Whilst its important security products are built well, the same applies to any technology in use today. The story doesn’t end when a product leaves the factory/software house - we still need confidence that its resilience will be maintained throughout its lifetime. That means we have to move away from 'point in time' assessment, towards a situation where we have confidence that technology will remain usable and resilient throughout its life cycle. In other words, we need more continuous assurance.

Whilst previous approaches to product assurance have given a nod to the development environment, the focus has been on the security functionality – because that’s the interesting stuff. It is, but ultimately, how can you have confidence in that functionality (especially over time) if the underpinning development environment is not up to scratch? Following the “Secure by Design” philosophy outlined in the National Cyber Security Strategy, our approach needs to tackle the root causes of product vulnerability and not just the symptoms.

Making it easy for people to do the right thing

People often have to work hard to be secure and that’s frequently an unfair burden of responsibility when you’re talking about complex technologies. Usability, especially when it comes to security, needs to be a core part of our strategy.

The NCSC has always advocated for usability, for effortless technology. Our technology assurance strategy will encourage manufacturers to help the people who use their products by ensuring usable security is built in by default.

It’s all about confidence

Whilst we need technology that is suitably resilient to cyber attack, we also want confidence that it really “does what it says on the tin”.

Establishing that a product comes from a manufacturer that has good engineering practices is the first step on the journey to gaining that confidence. If it’s a piece of general technology, that is probably enough, but if it’s got security functionality, you also want confidence that’s been properly implemented.

The process of gaining confidence starts with a good set of principles that describe the key security requirements and ends with appropriate evidence they’ve been met. Ultimately, it’s all about the evidence and how much of it you need…and that comes back to the risks and impacts.

If you need high confidence that the technology you are using is going to manage those risks and impacts then you might look for independent assessment, but if the risks and impacts are lower, a vendor publicly asserting that they meet the requirements may be all the confidence you need. To be sufficiently flexible, our assurance strategy needs to take all this into account.

Making informed decisions

Ultimately, we want to help people buy the right things to help them manage their cyber security risks.

A badge or certificate is often used as evidence that some criteria or others have been met. I’m still proud of the cycling proficiency certificate I earned when I was 11. This, my parents took as evidence I could safely cycle on the road and stop scaring pedestrians. That worked because the criteria for gaining the badge were simple, but it’s not the same when it comes to assuring complex technology.

In the past, our approach has followed exactly that path, trying to condense a whole load of complex issues into a “certificate of goodness” together with some caveats in fine print at the bottom. The problem is that these days, it's often the caveats that can be important in a particular use-case, but are overlooked as people focus on the certificate.

Such certificates have a place, but our strategy needs to recognise that different customers will need different things. We should aim to ensure our strategy is able to help citizens make informed choices when buying commodity technology, as well as providing appropriate information to help organisations chose technology that will help them be cyber resilient.

But what about the demand?

I often hear vendors say, “Why should I make my product more resilient if customers are not demanding it, it’ll just make me less competitive?” I can’t argue with that.

However, improving the cyber resilience of software in the UK is a major part of making the UK a safe place to live and work online. It also aligns with the Integrated Review and vision for the UK as a technology leader. So, we must find ways of incentivising the development of products that meet that need, and simultaneously, growing the ecosystem that can provide assurance capability to more people on our behalf.

The forthcoming Consumer IoT Code of Practice legislation is an example of this in practice, but we recognise that some organisations will need more help to improve their development process if they are going to be part of this revolution in technology assurance. We will need to work with colleagues across government to find innovative ways to do that.

And finally, this is a marathon, not a sprint

Alongside the assurance ecosystem that will help more people choose great technology that will keep them safe, we also need to put in place the kind of capability we know we will need in 5-10 years time.

We need to respond to the rapid changes in technology today and enable the future technology ambitions of the UK, not hamper them. That will take time to build.

 

Chris Ensor
Deputy Director for Cyber Skills and Growth

Written by

Chris Ensor

Deputy Director National Resilience Capabilities, NCSC