Multi-factor authentication and secure communications in a food plant covered by NIS2

Content of the requirement and who it covers in the food industry

Art. 21(2)(j) of the NIS2 Directive covers multi-factor or continuous authentication, secured voice, video and text communications and secured emergency communication systems within the entity. The requirement combines two areas: how the identity of people and devices is confirmed, and the channels through which the entity communicates in a crisis situation. It is not about any communication tool, but about one whose configuration and access can be controlled on the entity's side.

In the food industry, the sectoral scope follows from Annex II to the NIS2 Directive, which covers the production, processing and distribution of food. The Directive generally covers medium and large entities from the sectors listed in Annexes I and II, so qualification depends on meeting size thresholds, not on the activity profile alone. The national legal framework was amended by the Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts, announced on 2 March 2026 in Journal of Laws (Dz.U.) 2026 item 252, which entered into force on 3 April 2026.

In a food plant, the requirement affects both office staff and people operating lines and supervision systems. In emergency situations, communication runs in parallel through several channels, and access to them is sometimes shared. Therefore, compliance assessment starts with an inventory of accounts, devices and communication channels and with identifying which of them are used to respond to incidents.

• Multi-factor or continuous authentication for access to systems and services covered by the requirement.
• Secured communication systems within the entity, independent of public channels.

Generic scenario: a food plant's problem

A sample food plant produces and processes food, so it falls within the scope of Annex II to the NIS2 Directive. With the digitalisation of production lines and control systems, the number of channels through which staff pass instructions and report irregularities grows. In an emergency situation, such as a cold store failure or a batch of raw material being stopped, the key question becomes whether decision-makers can communicate quickly and securely.

In a typical scenario, some communication takes place via ordinary phones and messengers, and access accounts to production and business systems do not everywhere require a second factor. The plant also has not established which voice, video or text channel is used to pass instructions in an emergency situation. In an audit, it is then difficult to show how the identity of people issuing instructions is confirmed and how the communication itself is secured.

The risk grows when contractors and external service providers also have access to systems, and passwords are sometimes shared between shifts. A single event, for example account takeover through phishing, can turn into a disruption of production continuity. The plant therefore needs to organise authentication and designate secured communication channels for emergency situations.

• Access to production and business systems without a second authentication factor.
• No designated, secured voice, video and text channels for emergency situations.
• Shared accounts and contractor access make it difficult to attribute actions to a specific person.

Solution: division of tasks between the system and other tools

The division of tasks should be based on a map of the elements of this requirement. The part concerning strong authentication of users and privileged accounts belongs to the identity and password policy catalogue, usually managed by the IT or OT department. The communication layer within the entity, including voice, video and text channels for emergency situations, requires a separate determination of whether corporate solutions or dedicated alarm systems are used.

A food plant should document which systems perform multi-factor authentication and which handle crisis communication, and indicate the owner of each of these areas.

The boundary of responsibility should be described in the procedure, together with information on who configures authentication, who tests the communication channels in emergency situations and where the evidence from these activities is stored. Such a division organises the work of the OHS, maintenance and IT/OT departments and makes it easier to indicate which elements of the requirement are covered by the systems and which require separate tools.

• Designation of the owner of the multi-factor authentication and privileged accounts area.
• Description of how communication channels are tested and how evidence from these tests is stored.
• Indication of which elements of the requirement are outside the scope of InnerWeb and require action by the IT/OT department.

How InnerWeb supports the indicated elements of the requirement

In the area of multi-factor authentication, InnerWeb can support compliance with the requirement of Article 21(2)(j). The second login factor, implemented with an e-mail code or TOTP, is enabled for a selected installation. A trusted device is not asked for the second factor on every login, which reduces friction in the operators' daily work. Enabling MFA is a configuration decision of the plant, not a default state of the system.

In an emergency situation, a reliable notification channel is important. The user can enable and disable e-mail notifications for individual events, while notifications relevant to security remain mandatory and cannot be disabled. This mechanism supports the element of the requirement concerning mandatory notifications, but it is not a secured communication system.

For installations behind network isolation, InnerWeb stores alarm webhooks in a persistent queue received by an external poller, so the plant does not have to open outbound traffic and a stored webhook is not lost when the connection is blocked. Delivery depends on the polling frequency of the queue.

The audit evidence resulting from these functions includes the MFA configuration for the installation, the notification settings and the records in the persistent webhook queue. The remaining elements of the requirement, including communication in emergency situations, must be ensured by separate solutions and documented outside the system.

Outcome and conclusions for the audit

The outcome of implementation at a sample food plant is an organised body of evidence that the requirement of Article 21(2)(j) is met in practice: the multi-factor authentication policy covers privileged accounts and remote access, and emergency communication channels have assigned owners and documented rules of use. The auditor receives a consistent description of the actual state instead of declarations.

The conclusions for the audit come down to three elements: up-to-date requirement documentation, an evidence register with dates, and an indication of which elements of the requirement are handled by external tools and which remain the task of the IT department. This separation prevents overstating the scope of declarations and shows gaps without the risk of an allegation of non-compliance.

The national legal basis is established: the amendment to the National Cybersecurity System Act (KSC) entered into force on 3 April 2026, so review and documentation update deadlines can be referenced to the applicable legal state. Conclusion for the plant: maintain evidence on an ongoing cycle, not as a one-off before the audit.

• Collect evidence with the date of creation and the owner indicated, to demonstrate continuity in meeting the requirement.
• Describe in the documentation the division of responsibility between the system, external tools and the IT department.
• Plan a review of authentication and emergency communication policies in conjunction with the applicable legal state.