Recorded-capture processing
Lab work includes recorded-capture ingestion and selected software integration checks. These checks do not establish complete detection coverage or performance at your site.
VALIDATION
Evidence before promises.
Review what has been checked, what remains open and the evidence required for a scoped factory installation.
Validation / evidence before promises
Know what is established.
Know what comes next.
Dedicated appliance & live capture
Physical capture, collection freshness, packet loss, restart recovery and installed isolation still require appliance and site acceptance.
Your installation, your evidence
Agree the collection point, protocols, retention and success criteria. Establish what the installation can observe and detect, with gaps and owner decisions recorded.
Pre-launch validation continues. Evidence preparation supports review; it does not establish compliance or award certification.
SUPPORTING DETAIL
Inspect the supporting evidence.
Choose the topics relevant to your site, scope and review.
Testbed and field validationInspect scope, evidence quality and remaining acceptance work.
VALIDATION STATUS / CONTROLLED FACTORY PILOTS
Evidence first. Results when they are ready.
The examples on this website are synthetic. Verified factory performance results will be published only after a scoped pilot, evidence review and permission to share the findings.
Demonstration material
Supplied interface captures and a synthetic evidence pack explain the review workflow. They do not establish production performance.
Inspect the examplesEngineering acceptance
Agree the reference asset list, observation window, capture coverage, packet loss checks and operational safeguards before evaluating a site.
Review deployment responsibilitiesField findings
Future results should identify scope, method, duration, limitations and approval to publish. Anonymous reporting still requires a verified source.
Discuss a design-partner pilotWhat a verified pilot case study will contain
- Scope: site or anonymised context, authorised collection points, device reference list and observation period.
- Method: baseline assumptions, capture coverage, comparison method and acceptance criteria agreed before testing.
- Findings: measured results with supporting records, unresolved identity or coverage gaps and practical review actions.
- Limits: traffic not observed, encrypted or silent devices, exclusions and conditions affecting interpretation.
- Approval: a named review owner and customer permission before any identifiable or anonymised results are published.
No customer name, endorsement, success metric or production claim is implied by the current synthetic demonstrations.
Release engineering checkpointRead the retained checks and outstanding release items.
ENGINEERING CHECKPOINT / 4 NOVEMBER 2026
Verified maintenance. Further acceptance ahead.
A targeted SASL dependency update has been deployed and checked in the current engineering environment. This is a bounded maintenance result, separate from factory-pilot acceptance.
Targeted dependency maintenance
- The tested collector image and shared worker/scheduler image were deployed.
- All nine platform services were healthy after verification; the six other services stayed unchanged.
- Protected Kerberos library hashes and retained dependency checks passed.
- Isolated ingestion, database, job and retention checks passed before deployment.
What still needs evidence
- Dedicated-appliance and physical SPAN/TAP capture acceptance.
- Supported abnormal-command paths tested from packet to alert.
- Remaining security findings and release decisions.
- Licensing review and scoped factory-pilot validation.
Technical scope of this checkpoint
On collector, worker and scheduler, libsasl2-2 and libsasl2-modules-db were verified at 2.1.28+dfsg-10+deb12u1. The running image identities matched the tested candidates. The collector and worker candidates were scanned before deployment, and isolated integration checks compared the running and candidate images.
The deployment verification also checked retained source fingerprints, runtime configuration, mounts and network membership. Environment ordering, empty DNS-list representations and mount-list ordering were compared without discarding their values or security properties.
No LDAP/SASL server-negotiation test or factory performance claim follows from this checkpoint. Remaining findings require their own evidence and decisions. Overall release status: Gate 14 HOLD.
These results do not establish a completed security assessment, certification, live capture performance or factory readiness.
Explore the architecture and capture pathsDetection and interpretation limitsReview the difference between an observation and a security conclusion.
CLEAR FINDINGS / HUMAN REVIEW
What happened. Which device. What to check next.
Keep the first view practical for a small plant team, with technical evidence available when it is needed.
Existing rule paths
The retained code includes unexpected-peer and reviewed-zone checks, protocol-anomaly and security-notice handling, and MQTT policy-notice handling.
Rule-level checks are bounded evidence. Traffic coverage, configuration and operational context still determine what can be detected.
Command-level acceptance
Unauthorised Modbus writes, Siemens S7 commands and controller changes are not presented as fully validated coverage. Each supported command path needs an explicit approved policy and a packet-to-alert acceptance test.
Recording a function code alone does not establish authorisation or physical process effect.
OTCogniShield observes and supports review. It does not block commands, isolate machinery or change controller settings.
Review capture paths and visibility boundaries