With the European Union’s NIS2 Directive now in full force, the lines between physical and cybersecurity have irrevocably blurred, creating a new and challenging compliance landscape. For organizations managing critical infrastructure, the stakes have never been higher, with fines for non-compliance reaching up to 10% of annual turnover. To navigate these complexities, we are joined by Malik Haidar, a cybersecurity expert who has spent his career on the front lines, defending multinational corporations from sophisticated threats. He brings a crucial business-centric perspective to the technical world of security, specializing in the very nexus of physical access and cyber resilience that NIS2 addresses.
In our conversation, Malik will break down the practical realities of the NIS2 Directive. We’ll explore the initial steps essential and important entities must take to assess their operational risks, contrasting the needs of large organizations with those of their smaller suppliers. We will delve into the hidden vulnerabilities that emerge when physical and digital security systems converge and discuss the critical arguments for upgrading legacy systems. Malik will also provide a clear framework for fortifying access control—from credentials to controllers—and offer guidance on vetting vendors and preparing incident response plans for this new, interconnected threat environment.
The NIS2 Directive now impacts a wider range of organizations, including their supply chains. What are the first practical steps an “essential entity” in the transport or healthcare sector should take to assess their risk, and how does this differ from their smaller suppliers? Please share some examples.
The absolute first step, for any organization, is to conduct a thorough operational risk assessment. NIS2 is fundamentally about building resilience, and it deliberately avoids a one-size-fits-all checklist. For a large hospital, that assessment is a massive undertaking. You’re not just looking at servers; you’re mapping out how a compromised door lock in a pharmaceutical storage room could lead to a data breach of patient records. You’re considering the physical security of a data center that controls life-support systems. The scope is enormous, and the potential for severe disruption is a constant, palpable threat.
For a smaller supplier, say a company that provides software for the hospital’s visitor management system, the assessment is much more focused. Their primary concern is how their product could become a trojan horse. They need to ask: “Could a vulnerability in our code allow an attacker to gain a foothold in the hospital’s network? Is our own internal security robust enough that we aren’t the weak link?” The directive casts a wide net, even impacting companies with as little as €10 million in revenue, so this isn’t just a concern for the big players. The core difference is scale and scope, but the fundamental responsibility to identify and mitigate risk is the same for everyone in the chain.
With nearly half of IT departments now fully consulted on physical access control upgrades, what new vulnerabilities arise from this convergence? Could you walk us through a scenario where a weak physical access control system becomes the entry point for a significant cyber-attack, and what the consequences might be?
It’s great that 48% of organizations now have IT fully involved in physical access control, but this convergence is a double-edged sword. When you connect a physical access control system (PACS) to the corporate network, you’re essentially creating a new door for cyber attackers. Imagine a scenario at a financial institution. An attacker finds a vulnerability not in the firewall, but in the firmware of a network-connected door reader at a branch office. They exploit it to gain access to the local network segment. From there, they move laterally, escalating their privileges.
Suddenly, the physical breach becomes a full-blown cyber crisis. The attackers aren’t just stealing a laptop; they’re inside the network, disabling alarms, altering access permissions for key personnel, and exfiltrating sensitive customer data. The initial entry point was a simple door reader, but the result is a catastrophic data breach, regulatory fines, and a complete loss of customer trust. It’s a silent, insidious attack vector that many organizations overlook until it’s far too late. This is precisely the kind of interconnected risk that NIS2 is designed to address.
Some organizations are still using physical access control systems that are over six years old. Beyond the obvious lack of modern features, what specific NIS2-related risks do these legacy systems introduce, and what is the most compelling argument for justifying the cost of a full upgrade to management?
It’s genuinely concerning that 14% of organizations are relying on systems older than six years. These legacy systems are a ticking time bomb from a NIS2 perspective. The most significant risk is the lack of support for modern encryption standards and secure communication protocols. They often use outdated, easily cloned credential technologies and have firmware that is no longer patched, leaving them riddled with known vulnerabilities. They become a soft target, an open back door into the network that no amount of firewalls can protect.
When I talk to management, the most compelling argument isn’t about shiny new features; it’s about shifting the conversation from cost to risk mitigation. I lay out the financial exposure in stark terms: the cost of a full system upgrade versus a potential fine of up to 10% of your global annual turnover under NIS2. That’s a number that gets everyone’s attention. Then I add the costs of reputational damage, operational downtime, and incident response. Suddenly, the investment in a modern, secure, and compliant PACS doesn’t look like an expense; it looks like one of the most prudent insurance policies the company can buy.
You’ve outlined a “good, better, best” framework for securing credentials, readers, and controllers. Can you detail the single most critical “baseline” improvement an organization can make in each of these four areas to quickly reduce its risk profile and demonstrate a commitment to NIS2 compliance?
Absolutely. This framework is about making immediate, impactful progress. For credentials, the single most critical baseline is moving to encrypted smart cards or virtual credentials. The data on the card and the data communicated to the reader must be protected. Using AES 128 encryption as a standard is a non-negotiable starting point to prevent simple card cloning.
For readers, the baseline is ensuring they not only support these encrypted credentials but also have a secure element on board to protect the encryption keys themselves. A reader without a secure element is like a vault with the key taped to the door. It completely undermines the security of the entire system.
When it comes to controllers, the most critical baseline is network hygiene. You must connect them to a secure, dedicated VLAN, deactivate any unused interfaces, and immediately change all default passwords and configurations. Controllers are the brains of the system, and leaving them exposed on the main corporate network is an open invitation for an attacker.
Finally, for access control servers and clients, the baseline is diligent patch management. You must host them on a secure VLAN and commit to keeping all software and operating system patches up to date. Choosing a vendor that is transparent about Common Vulnerabilities and Exposures (CVE) reporting is also part of this baseline. These four steps form a solid foundation for building a truly resilient system.
Since NIS2 compliance extends to the entire supply chain, what specific questions should an organization ask a potential PACS vendor? Beyond certifications like ISO 27001, how can a company verify that a vendor is truly prepared for the evolving threat landscape and not just checking a box?
This is a crucial point. Certifications like ISO 27001 are a good starting point, but they can become a box-ticking exercise. To go deeper, I advise clients to ask very specific, probing questions. First, ask the vendor to describe their Secure Software Development Lifecycle (SDLC). Do they adhere to standards like ISA/IEC 62443-4-1? This shows if security is baked into their products from the very beginning, not just bolted on as an afterthought.
Second, ask about their vulnerability disclosure policy and their process for providing patches. You want a partner who is proactive and transparent, not one who hides security flaws. Ask for evidence, like their history of CVE reporting. Finally, ask them to demonstrate how their solution provides end-to-end, interoperable protection. You’re not just buying a reader; you’re buying into an ecosystem. You need to see a commitment to securing the entire chain, from the credential to the server, and a willingness to meet or exceed new standards as they emerge. A vendor’s passion and deep knowledge—or lack thereof—will become very apparent in how they answer these questions.
NIS2 requires organizations to report significant cybersecurity incidents within 24 hours. How should an organization’s incident response plan specifically account for an event that originates from a compromised physical access control system? What unique challenges does this present for the reporting process?
The 24-hour reporting window is incredibly tight, and it forces a level of preparation many aren’t ready for. When an incident originates from the PACS, the biggest challenge is that it requires a coordinated response from teams that often operate in silos: physical security, IT security, and facilities. Your incident response plan must explicitly bridge these gaps. It needs a clear protocol that starts the moment a “door forced open” alert is correlated with unusual network activity. Who gets the call at 3 a.m.? Is it the head of security or the CIO? The plan must answer that instantly.
The unique reporting challenge is one of attribution and impact assessment. Within hours, you need to determine if a physical breach led to a data breach. Was proprietary information stolen from a server room? Was a critical system disabled? You have to move from “someone broke a door” to “this is a significant cyber event that may cause severe operational disruption,” and you have to do it with incomplete information. This requires pre-defined playbooks and regular drills involving all three departments, so when a real event happens, the response is muscle memory, not panicked confusion.
What is your forecast for physical access control?
I foresee a rapid acceleration away from isolated, proprietary systems toward open, IP-based platforms that are managed as critical IT assets. The future of access control is inextricably linked to identity management. We’ll see a much deeper integration with IT systems, where a single digital identity governs a user’s access to everything—from cloud applications to the front door of the office. Technologies like mobile credentials and biometrics will become the standard, not the exception, because they offer superior security and a better user experience. Most importantly, driven by regulations like NIS2, the mindset will shift completely. Physical access control will no longer be seen as a facilities management tool but as a fundamental pillar of an organization’s holistic cybersecurity strategy. The vendors and organizations that fail to embrace this convergence will simply be left behind, exposed and non-compliant.
