Camera systems often outlive the companies that install them. In this Help Net Security interview, Rob Janssens, EMEA Cyber Security Director at Hikvision Europe, discusses what happens when the integrator is gone, the documentation is lost, and nobody holds the admin credentials.
He explains why products should let customers recover control on their own, and how secure-by-default settings reduce the damage of predictable installation mistakes. He also weighs source code escrow, country-of-origin rules, and what evidence vendors can and cannot offer critical infrastructure operators.
Most camera estates outlive the integrator who installed them. What happens operationally in year six when the installer has folded, the commissioning documentation is gone, and nobody has the admin credentials?
That situation is more common than the industry would like to admit. A camera may have a ten-year operational life, while the company that installed it may not exist in the same form five years later. People move jobs, contractors change, and documentation gets lost.
From our manufacturer’s point of view, we have to accept that reality. The customer owns the system. They should not be dependent on a particular installer to keep control of it.
That is why the basics matter so much. The device needs a secure activation process, proper account controls, a controlled way to recover or reset access, firmware maintenance, and enough audit information for the customer to understand what has happened to the device. We require mandatory password creation during activation, login-failure monitoring, IP filtering and controlled SSH access. Those are useful controls, but they only work properly if the device remains under the customer’s ownership and is maintained.
The other change I expect to see is better asset management. Security teams are getting much better at discovering devices, checking configurations and identifying systems that have fallen outside normal management. AI will help with that, but I would not make AI the answer to a basic governance problem. The first requirement is still ownership, governance, and a documented recovery process.
If an installer disappears and the customer can no longer administer its own cameras that is a lifecycle problem. Manufacturers should design products so that the customer can recover control without having to go back to the original installer.
A significant share of physical security kit is specified by procurement teams buying on price, installed by electricians, and never touched again. How do you engineer for a channel that will not read your hardening guide?
We have to be realistic about how these systems are installed. You cannot build a security strategy around the assumption that every installer will read a long security manual and then remember it five years later.
The product therefore has to do more of the work.
For example, requiring a new password when a device is activated is much better than shipping equipment with a universal default password. Services that are not needed should not simply be exposed because they happen to be available. Remote administration should be controlled, and the device should make the secure choice the easy choice.
This is also where the distinction between secure-by-design and secure-by-default is important. Secure-by-design means security is considered throughout development, testing and maintenance. Secure-by-default means the customer does not have to become a security specialist just to get a reasonably safe initial configuration.
Our Security Development Lifecycle covers the product from requirements and design through development, verification, release and maintenance. That is the right direction for the industry. Security cannot be something added at the end of the installation project.
Of course, no manufacturer can compensate for every bad network design. If somebody puts a camera directly on the public Internet, disables controls, and never patches it, there is still a risk. However, we can make the product much more resistant to predictable mistakes.
How do you handle an integrator who is knowingly deploying devices with security features disabled because a customer wants remote access to work in five minutes rather than five hours?
First, I would want to understand exactly what has been disabled and why. There are legitimate operational requirements for remote access, but ‘it works’ is not the same as ‘it is secure’.
If an integrator deliberately turns off a security control, the customer should know what that means. That decision should not be hidden in an installation script or made simply because it is quicker.
There is also a product responsibility here. High-risk settings should not be something that can be changed accidentally. The user should be able to see that a security control has been weakened, and important changes should leave an audit trail.
The better answer to the remote-access problem is normally architecture rather than disabling security. Restrict access, use appropriate secure protocols, segment the video network, and only expose the services that are actually required. Our product-security guidance, for example, recommends limiting remote access and using more secure methods such as VPNs rather than exposing systems directly to the Internet.
I would not pretend that customers never make risk decisions. They do, and sometimes they have good operational reasons. Our responsibility is to make those decisions visible and to give customers a secure baseline to start from.
The threat environment is changing as well. Automated scanning means that a configuration which might have remained unnoticed for months can be found very quickly. That makes ‘we have always done it this way’ a poor security argument.
Several European buyers now require source code escrow, third-party binary analysis, or country-of-origin restrictions. Which of those measures do you consider security theatre, and which have improved your products?
I would be careful about calling any of these measures ‘security theatre’ in isolation. They address different risks.
Independent testing and vulnerability research are useful because another engineer can find something our own teams missed. Binary analysis can also be valuable, particularly when a customer wants to understand what is actually running on a device rather than relying only on documentation.
Source-code escrow is different. I can understand why a customer would want it, especially for business continuity or supplier risk reasons. But having access to source code is not, by itself, evidence that a product is secure. You still need secure development processes, code review, testing, vulnerability management, control of dependencies, and a trustworthy build and update process.
Country-of-origin requirements are even more complicated. Customers operating critical infrastructure have legitimate legal, geopolitical, and supply-chain concerns. Those requirements need to be addressed honestly. At the same time, nationality alone should not replace objective, technical security evaluation. The useful question is what evidence and technical controls are in place and what risks they address.
From our side, the measures that have the technical value are the ones that create repeated feedback security testing, vulnerability disclosure, testing, secure development requirements, and continuous improvement.
That is also why transparency matters. A customer should be able to ask how security is handled and then verify the answer where appropriate.
Hikvision sits under US sanctions and continued scrutiny in several European countries. When a critical infrastructure operator asks you why they should trust your firmware, what evidence do you put on the table, and what can you not prove to them?
I would start by saying that they should not trust a vendor simply because the vendor says its firmware is secure. They should ask for evidence, and we should be prepared to provide evidence that is appropriate for the product and the customer.
There are several parts to that. One is the development process. Hikvision has published information about its Security Development Lifecycle and about the controls it uses during design, development, verification and maintenance. We also publish product-security information and operate a very mature certified vulnerability reporting process, certified under ISO/IEC 29147 & ISO/IEC 30011.
Also, our AI is edge, this means that the AI is running directly on the camera, without requiring external connectivity. We are also among the industry pioneers to achieve ISO/IEC 42001 certification. This is the world’s first certifiable international standard dedicated to AI standards for an Artificial Intelligence Management System (AIMS), providing a structured framework for AI governance. This standard helps us to ensure that the AI systems are ethical, transparent, secure, and aligned with stakeholder expectations.
Another part is the product. Customers can look at things such as authentication, password controls, secure management protocols, firmware protection, and update mechanisms. For example, Hikvision product-security documentation describes password requirements and an activation process that requires a new password. It also describes anti-downgrade protection and SSH being disabled by default unless an administrator enables it.
Then there is independent validation. Customers may perform their own testing, use third-party assessments, or conduct binary and network analysis. I see that as a normal part of doing business with critical infrastructure. A serious customer should challenge its suppliers.
What we cannot prove is that a particular piece of software contains no vulnerabilities. No responsible manufacturer or software vendor can make that claim.
The same applies to trust. A certification or a white paper cannot manufacture trust. The better approach is to give customers enough information to assess the technology, keep improving the products, respond when vulnerabilities are reported, and accept independent scrutiny. For me, that is a more credible position than asking customers simply to take our word for it.