Verification of security features

This section provides methods to check whether security mechanisms are properly configured and active:

Mechanism	Verification
Authenticity and Integrity of Configuration	The audit logs indicate that the authenticity and integrity check is enabled (log message "Verification of configuration files has been enabled...") and that the configuration has been successfully verified (log message "The archive has been verified successfully..."). If the authenticity check is disabled, or if the configuration failed the verification, this will also be indicated in the audit logs accordingly
Signed package structure and deployment consistency	Before upload, verify that the zip archive contains only config.tar and signature.sig and no additional files. After upload, verify that no new package was created between signing and deployment (same artifact hash/checksum in CI/CD or release process).
Secure Connection MQTT	The audit logs indicate for every new connection to an MQTT broker whether TLS (and/or certificates) are used and whether user authentication is used.
MQTT TLS hardening	Verify in the configuration and logs that TLS is enabled for external brokers, tlsInsecure is disabled, and the expected TLS version/profile is in use.
Secure Connection OPC UA	The audit logs will indicate for every new connection to an OPC UA server what security mode and what security policy is used. Confirm that it matches the desired settings.
MQTT Rate Limit	The logs indicate for every subscription to a topic on the MQTT broker what rate limit is used. rateLimit = 0 means that the rate limit is disabled, in which case the Data Gateway could potentially be vulnerable to DoS attacks via flooding (if the broker does not enforce a suitable rate limit).
MQTT wildcard and retained-message hygiene	Review configured topics and broker-side settings to confirm that broad wildcards are only used where required and retained messages are managed according to system safety requirements.