Security and compliance
An IEC 62443 compliance map — evidence, not a certificate
Every IEC 62443-4-2 component requirement was marked against the product one by one. What is met and what is not are both on this page, open gaps included.
Scope and target security level
Three components were assessed: Bella.API (authentication, authorisation, audit trail), Bella.ScadaRuntime (the separate Windows service that talks to the field) and the browser panel. The target security level is SL-2: resistance to intentional attacks using simple means and low resources.
Every line was verified against the repository as of 20 August 2026. Items still on the roadmap are marked as such here too — we do not colour a met requirement and a planned one the same way.
This page is the summary. The full 30-row table at component-requirement level, the zone and conduit diagram and the residual risk statement live in a separate document. We send it on request; a direct download link is not published yet.
Zones and conduits
Most of the compliance comes from the architecture. The system is split into four zones, and there is no direct network path between the field and the operations zone.
Field (Level 1)
PLCs, RTUs and smart devices. Modbus TCP/RTU, S7, EtherNet/IP, OPC UA, IEC 60870-5-104, DNP3, BACnet, IEC 61850, MQTT. Most of these protocols carry no authentication — a limit of the protocol rather than the product, which is exactly why it is treated as its own zone.
Control (Level 2)
Bella.ScadaRuntime. It only polls; it accepts no inbound connections. When the link drops it writes to a 10,000-message store-and-forward buffer and replays on reconnect.
Operations (Level 3)
Bella.API, PostgreSQL, Redis. Authentication, authorisation and the audit trail live here. A write to the field travels API → Redis → runtime → device, and permission is checked at every hop.
Enterprise / client
The browser panel and MES/ERP integration. The conduit is TLS over HTTPS and WSS; MES and ERP connect through an API key or the OPC UA server.
FR1-FR7 summary
IEC 62443-4-2 groups component requirements into seven foundational requirement families. The status below is at family level; the requirement-level table (CR 1.1, CR 2.5 and so on) is in the dossier.
| Foundational requirement | Status | What Bella SCADA provides |
|---|---|---|
| FR1 — Identification and authentication | Met · except PKI | Human users authenticate with identity plus JWT and a TOTP second factor with trusted-device registration. Machines and services use scoped API keys with an expiry date — the raw key is never stored, only its SHA-256 digest. Five failed attempts lock the account for 15 minutes. The login screen carries a legal use notice written by your organisation. There is no certificate-based (PKI) user identity. |
| FR2 — Use control | Met · signature binding in progress | Permission-driven authorisation: an unauthorised user never sees the item, so there is no hidden button to probe. Idle session lock, session list and remote termination. Entity- and field-level audit records, a separate security log, UTC timestamps. An electronic signature ledger (meaning plus reason) exists, but signature is not yet enforced on tag writes or recipe application. |
| FR3 — System integrity | Partial | HTTPS is required and HSTS is on; live data rides WSS. Input validation, an HMI document schema, raw HTML disabled inside markdown. No stack traces in production. Zero clock skew on tokens and refresh token rotation. The audit trail is SHA-256 chained. Release packages are not code signed (a digest list is produced), and there is no dedicated self-test for security functions. |
| FR4 — Data confidentiality | Met · data at rest is a deployment task | TLS 1.2+ in transit. SHA-256 for API keys, PBKDF2 for passwords. Retention limits and automatic cleanup for both trend data and audit records. Encryption at rest is a deployment responsibility — PostgreSQL TDE or disk encryption — and we do not list it as a product feature. |
| FR5 — Restricted data flow | Deployment responsibility | The architecture supports segmentation: the runtime accepts no inbound connections and there is no direct path between operations and the field. But firewall rules and VLAN separation are applied during deployment; software alone cannot segment a network. |
| FR6 — Timely response to events | Partial | Audit and security log screens in the panel, with export. Audit write failures are counted; past a threshold they land in the security log and notify an administrator. Structured logging and health endpoints exist, but there is no ready-made SIEM feed. |
| FR7 — Resource availability | Met · drill still pending | Partitioned rate limiting (login, general, write), a bounded store-and-forward buffer, alarm flood suppression, trend retention cleanup. Swagger is exposed only in development. Configuration export and import. CycloneDX component inventory. Backup and restore are documented, but the restore drill has not been run. |
Rows marked "deployment responsibility" are not shortcomings — the standard assigns them to the installation. We still spell out who does what, so they do not fall off the commissioning checklist.
The audit trail: deletable, but not concealable
Audit records are linked by a SHA-256 hash chain: each record carries the digest of the one before it. Chain verification runs from the panel and reports every break individually.
We do not say "immutable", because it would not be true. A privileged user with direct database access can delete or alter an audit record. What the chain does is make that impossible to hide: every digest after the touched record stops matching, and verification points at exactly where the chain broke. Auditors ask about this distinction, so we raise it first.
Records written before the chain was switched on are reported as "unverifiable" rather than "broken" — labelling historical data as tampered would only manufacture false alarms.
The audit trail is itself managed: a daily retention cleanup runs, and the cleanup is written to the audit trail too. A failed audit write is never swallowed; failures are counted, and past a threshold they reach the security log and an administrator. All timestamps are UTC.
Session and access security
These ship with the product and are configured from the panel. Nothing here is a paid add-on.
| Control | Default | Behaviour |
|---|---|---|
| Two-factor authentication | Enabled per user | TOTP via an authenticator app, with trusted-device registration. A trusted device stops the code prompt on every login but still records the device binding in the audit trail. |
| Idle session lock | 15 minutes | The timer is shared across tabs, so moving the mouse in a second tab does not postpone the lock. The lock screen is modal and hides the data behind it. Unlocking re-verifies the password, and failed attempts count towards the account lockout. A value of 0 disables the lock — that call is yours. |
| Failed login attempts | 5 attempts → 15 min | The error message does not distinguish a wrong username from a wrong password, so valid usernames cannot be enumerated. |
| Legal use notice | Your text | Shown on the login screen before the form. You write the wording in system settings; leave it empty and the notice is not drawn at all. We do not put words in your legal department's mouth. |
| Permission catalogue | Assigned per role | Every endpoint checks permission, and an unauthorised user never sees the item. Assignment is its own permission: being able to view a record does not imply being able to hand it to someone else. |
| Session lifetime and termination | 60 min access / 1200 min refresh | Users can list their own open sessions; an administrator can terminate one session or all of them remotely. Token validation runs with zero clock skew. |
| Machine and service identity | API key | The raw key is never stored — only its SHA-256 digest. Keys are scoped and carry an expiry date. A lost key cannot be read back; you issue a new one. |
| OPC UA server | Disabled by default | When enabled it runs signed and encrypted with Basic256Sha256, requires a username and password, and rejects untrusted client certificates — certificates are moved into the trust store by hand. Separate switches exist for insecure mode and anonymous access; turning them on writes a warning to the log and must be recorded as residual risk in your dossier. |
Supply chain and release integrity
Component inventory (SBOM). Every release produces a CycloneDX list of .NET and npm dependencies. Your security team can feed it straight into their own scanner instead of taking a vendor report on trust.
Vulnerability status. As of 20 August 2026 the known-vulnerable dependency scan comes back clean across all four projects. Nine advisories were closed before that, one critical and five high. We put a date on it because this kind of statement is only worth its freshness.
Release integrity. Each release ships with a SHA-256 digest list, so you can confirm that the file you downloaded is the file we built.
But the packages are not signed. The code signing certificate has not been purchased yet. A digest list proves the file is intact; it does not prove who produced it — against an attacker who can also replace the digest list, both fall together. Once the certificate is in place the same release script will sign as well. Closing this gap takes a purchase, not code, which is why it is still listed here.
Mapping to the Turkish energy ICS cyber security regulation
In Turkey, the EPDK regulation on information security for industrial control systems places the obligation on the licence holder, not on the software vendor. The table separates the part of that obligation the product covers from the part that stays with you.
| Control area | What the product covers | What stays with you |
|---|---|---|
| Asset inventory | CycloneDX software component list; connection, device and tag inventory in the panel; full configuration export. | Field hardware inventory (PLCs, RTUs, switches) and keeping it current. |
| Authorisation and access control | Permission catalogue, role assignment, two-factor authentication, idle lock, session termination. | Who gets which role, joiner/leaver process, limiting the number of privileged accounts. |
| Network segmentation | Four-zone architecture; the runtime accepts no inbound connections; no direct path from field to operations. | Firewall rules, VLANs, DMZ design and periodic review of the rule set. |
| Logging and traceability | Hash-chained audit trail, separate security log, UTC timestamps, export from the panel, retention management. | Central log collection, write-once (WORM) archiving, and setting retention to match the regulation. |
| Incident management | ISA-18.2 alarm management, security log, audit write failure monitoring and administrator notification. | Incident response procedure, on-call rota, and meeting your own notification obligations. |
| Business continuity and backup | Backup and restore procedure, store-and-forward buffer, hot-standby redundancy (disabled by default). | RTO/RPO decisions, where backups are held, and running restore drills. |
| Supply chain security | SBOM, vulnerable dependency scanning, SHA-256 digest list per release. | Vendor assessment, security clauses in the contract, and your update acceptance process. |
| Cryptography | TLS 1.2+ in transit, SHA-256 for API keys, PBKDF2 for passwords, Basic256Sha256 on OPC UA. | Certificate management and renewal, encryption at rest (TDE or disk), key custody policy. |
This table deliberately cites no article numbers. The regulation text has been revised, and article-level mapping depends on the scope of the installation; a numbered cross-reference is prepared for your dossier using your deployment details. A generic numbered table is something you, not us, would have to defend in the audit room.
Frequently asked
Are you IEC 62443 certified?
No. Certification comes from an accredited body and also requires IEC 62443-4-1 secure development lifecycle certification. What we have is a compliance map and evidence dossier: 30 component requirements marked one by one, the location of the evidence in the code, and a list of open gaps. If a specification says "certified", we state in the bid that we do not meet that clause.
Is your audit trail immutable?
We do not claim that. A privileged user with direct database access can delete a record. What the hash chain gives you is that deletion cannot be hidden: verification points at the exact break. True immutability requires shipping records to central WORM storage; that shipping is not in the product today — SIEM/WORM integration is handled per project.
Do you meet SL-3?
Our target is SL-2 and the product is designed to it. SL-3 adds further requirements such as PKI-based identity and a hardware key store; which of these are met today and which are handled within project scope is something we walk through item by item during the security review.
Can I attach the dossier to a tender?
Yes. The full document contains the zone and conduit diagram, the requirement-level table, the residual risk statement and the SBOM procedure, in a form you can attach as-is. We send it on request — a public download link is not published yet.
Are the field protocols encrypted?
Mostly not. Modbus, IEC 60870-5-104 and the common mode of DNP3 carry neither authentication nor encryption. That is a limit of the protocol, not a defect in the product — and no SCADA package solves it on its own. The answer is segmentation: the field conduit sits in its own zone and the runtime accepts no inbound connections. OPC UA and MQTT over TLS are encrypted.
Is our data encrypted at rest?
In transit, yes: TLS 1.2+. At rest, encryption is a deployment responsibility — PostgreSQL TDE or disk encryption. We do not present it as a product feature; it is a separate line on the commissioning checklist.
Can we keep everything on our own servers?
Yes. The product runs on your own servers and sending data to a cloud is never required. Cloud hosting is a separate option. For critical infrastructure the usual choice is an on-premises install inside an operations zone with no internet connection.
Ask for the compliance dossier
We send the full compliance statement, a sample CycloneDX SBOM and the release integrity procedure in a form you can attach to a tender. If you have a security assessment questionnaire, we fill it in and return it.