Security and IT architecture
PRECOG runs in a vendor-hosted cloud for a pilot and on a server of the customer in production. Both models follow the same security principles.
Deployment
Deployment models
The PRECOG Web API and the application services run in a cloud environment operated by Vida Soft and are reached over the internet. The measurement device uses the existing network of the customer, with Ethernet or an enterprise Wi-Fi, and needs no dedicated gateway. Authorised users work in a browser. Data is stored and processed in the EU.
A dedicated PRECOG server in the server room of the customer runs the API, the analytics, the AI, the database and the browser interface. The devices connect to the local API endpoint, so normal operation does not depend on an external cloud service.
The system is observational. It reads measurements and sends no control commands to the machines.
Edge
Measurement devices
- Only the services that are needed for measurement, connection and API communication are active.
- Outbound traffic uses an encrypted HTTPS channel.
- Each message is signed with a machine key (HMAC), which protects its origin and integrity.
- Network access to the device is limited by the Wi-Fi or Ethernet controls of the customer.
- Physical access, firmware management and maintenance follow controlled processes.
- If the connection is lost, the device keeps the records in its own storage and uploads them in order. A record counts as delivered only after the API has confirmed it.
Interface
API and communication
Transport
TLS 1.2 or later, and TLS 1.3 in the pilot. Unencrypted HTTP, FTP and Telnet are not needed in normal operation.
Authentication
Devices use an HMAC signature and a device identification. Services use dedicated accounts without interactive login. Integrations use a secret or a certificate.
Input and errors
The server validates type, range, length and format of every input. Error messages are generic and reveal nothing about the system.
Session identifiers are never sent as URL parameters. Access follows the principle of least privilege. Successful and failed API events are logged.
Data
Data and ownership
PRECOG processes technical telemetry, asset information, analytical results, events, user records and administrative logs. The processing has a defined purpose, access depends on the role, and material changes can be audited. A pilot package can be limited to anonymous technical values with a time stamp, a sequence number and a device identifier that describes nothing. It then contains no personal data and no machine name, serial number or exact location.
The data follows a managed lifecycle: collection, retention, use, backup and controlled deletion. Data files, backups and sensitive configuration are encrypted at rest. Keys and secrets are managed separately from the data, with restricted access and documented rotation and revocation.
Access
Access control
- Devices: HMAC machine authentication with a unique secret and replay protection.
- Users: a unique ID and a strong password, with multi-factor authentication where it is integrated.
- Administrators: separate named accounts, multi-factor authentication where integrated, and session logging.
- Role-based access: viewer, maintenance technician, maintenance manager, system administrator and auditor.
- Every role sees only the functions and data that it needs.
- Privileged rights are reviewed regularly, inactive accounts are revoked and access events are logged.
Operations
Logging, backup and patching
Logging
Audit, API, security, application, database and operating-system logs share a common time source, a source identifier, an event type, a result and a correlation identifier. Where a SIEM is integrated, the logs can be forwarded to it.
Backup and recovery
The backup model fits into the central backup of the customer: frequent database backups, a daily full backup, a configuration backup after each approved change and a system image before major changes. Recovery follows a documented sequence.
Directive
NIS2 Directive: what it asks
Directive (EU) 2022/2555, known as NIS2, sets common cybersecurity rules for essential and important entities in the EU. Each member state applies it through its own national law. Article 21 lists the risk-management measures that an entity has to take. Article 23 describes how significant incidents are reported.
The obligations belong to the operating organisation. A supplier cannot take them over. A supplier can offer a product that is built securely, documented clearly and easy to fit into the security programme of the operator. This is how PRECOG is designed.
PRECOG is an observational system. It reads measurements and sends no control commands to the machines, so it adds no way to influence a process. The architecture and the controls are described in the sections above.
Article 21
NIS2 measures and PRECOG
Each card names a measure from Article 21(2) and states what PRECOG provides for it.
The deployment model, the security zones and every network connection are documented, with source, destination, protocol, port and business reason. The operator can use this description directly in its own risk analysis.
Audit, API and security events are logged with a common time source, an event type, a result and a correlation identifier. Logs can be forwarded to a SIEM. Security events follow a classified process with a log-based investigation, a verification test and a documented closure.
The backup model fits into the central backup of the customer: database backups, a daily full backup, a configuration backup after each approved change and a system image before major changes. Recovery follows a documented sequence. A measurement device keeps its records during a network outage and uploads them in order.
The supported infrastructure is listed. Components at the end of vendor support are migrated. The ownership of the data and of the software is defined in writing, so the operator can assess PRECOG as a supplier.
Vulnerability assessments run before deployment, after significant changes and at regular intervals. Findings are ranked by risk, exploitability and business impact. Before go-live the external and internal attack surface is tested, and a retest confirms the fixes. Changes follow a controlled release process.
Penetration tests and retests, regular vulnerability assessments and the monitoring of the platform itself give evidence of how well the measures work. The platform monitoring follows availability, response time, error rate and use of resources.
Only the services that are needed are active. Unnecessary ports are closed, services run under non-privileged accounts and there is no direct remote administrator login. Training of staff is an organisational measure of the operator.
Communication uses TLS 1.2 or later, and TLS 1.3 in the pilot. Every device message is signed with a machine key (HMAC). Data files, backups and sensitive configuration are encrypted at rest. Keys are managed separately, with documented rotation and revocation. Old SSL and TLS versions and weak algorithms are disabled.
Access is role-based, with five roles from viewer to auditor, and follows the principle of least privilege. Privileged rights are reviewed regularly, inactive accounts are revoked and access events are logged. Each device has a unique identifier and a unique secret.
Users and administrators can use multi-factor authentication where it is integrated, and administrators have separate named accounts. The wireless connection of the devices can be protected with WPA3 Enterprise and 802.1X. Outbound traffic uses an encrypted channel.
Article 23
NIS2 incident reporting
An entity has to send an early warning within 24 hours of learning about a significant incident, a notification within 72 hours and a final report within one month. To do this the operator needs reliable facts quickly.
The logs of PRECOG share one time source and carry a source identifier, an event type, a result and a correlation identifier. They can be forwarded to the SIEM of the operator, where they join the other logs. The decision on whether an incident is significant, and the report to the authority, remain with the operator.
Sectors
Where NIS2 applies
The directive lists sectors such as energy, transport including air and rail, drinking water and waste water, health, digital infrastructure and the manufacture of electrical equipment and machinery. Airports, railways, utilities and manufacturers are among the organisations in which PRECOG monitors electric motors.
Whether an organisation is in scope depends on its sector, its size and the national law of the country where it works.
Scope
Scope of the NIS2 section
Do you have IT, security or NIS2 requirements that we should answer before a pilot?