Control the session
Bind identity, project state, destination, requested authority, maintenance scope, and time into one explainable decision.
ENGINEERING SESSION GOVERNANCE
Govern the engineering session—not only the workstation.
EWSP governs the Engineering Environment, application, project, controller, trust, policy, and evidence that define privileged engineering activity. It evaluates readiness before authorization, enforces the session decision locally, and preserves an explainable record before, during, and after the activity.
Deterministic policy Explicit engineering evidence Local Windows enforcement
EWSPLive authorization
● Protection Service connectedCURRENT SECURITY STATEAUTHORIZED
The engineering connection passed every mandatory check.
01ApplicationPASS
02WorkstationPASS
03EndpointPASS
04ProjectPASS
05PolicyPASS
Trust score100 / 100PERMITTED
THREE-MINUTE BRIEF
An Engineering Governance Platform.
EWSP governs engineering work from readiness through verified outcome. OT security protects industrial systems; EWSP governs the industrial engineering operations performed against them.
Preserve engineering context
Revoke a valid session when its project, target, tool, or approved operating condition changes.
See the boundary
Current capabilities, controlled validation, source-built work, and field-validation needs are labeled separately.
An independent authorization and evidence layer
It decides whether a defined engineering session should perform a privileged operation against an industrial asset.
Not EDR or antivirusNot passive OT monitoringNot a jump server or remote-access gatewayNot a PLC firewall or SCADA replacementNot a process-safety or SIS control
Safety boundary: Authorization verified does not mean process safe. PLC, SIS, interlocks, permissives, operating procedures, and process-safety engineering remain responsible for physical-process safety.
Where EWSP fits beside existing controls Learn more
TechnologyPrimary question
Firewalls
Can this network traffic flow?
EDR / HIDS
Is this endpoint or process malicious?
PAM
Who may use privileged credentials?
OT monitoring
What is happening in the plant?
EWSP
Should this engineering session perform this privileged engineering operation?
EWSP complements industrial engineering platforms, OT monitoring, EDR, PAM, and network access controls. These are architectural roles, not claims of current product integration.
THE FROZEN V1 CONTROL MODEL
Every stage answers one bounded question.
An Engineering Session is the complete governed context—not merely a connection, credential, or workstation.
01PASS
Application
Trusted engineering software
02PASS
Workstation
Approved Windows identity
03PASS
Endpoint
Verified industrial asset
04PASS
Project
Authorized project state
05PASS
Policy
Time and operation permitted
✓DECISION
Authorized
Communication permitted
Any mandatory check fails→BLOCK
The failed condition is explained and unauthorized communication is prevented.
Engineer→Control Point→Engineering Environment→Readiness→Application→Project / Parameter Set→Target Asset→Trust→Authorization→Protection Policy→Session Decision→Evidence
The EWSP Protection Service is the Control Point and sole policy authority. Connectors and readiness providers contribute evidence only.
Engineering Session context and governed lifecycle Learn more
01Engineer or authorized account
02Control Point
03Engineering Environment
04Engineering application
05Approved project and integrity state
06Target industrial asset and service
07Requested engineering operation
08Maintenance authorization and time window
09Observed runtime context
Authorization belongs only to the Engineering Session. Engineering Environment state is referenced—not duplicated—and any mandatory context change can withdraw session authorization while preserving the evidence.
Discover
Collect evidence without granting trust.
Approve exact scope
Review identity, integrity, destination, operation, and time.
Permit and verify
Enable only the bounded context and record the outcome.
Promote explicitly
Observation never promotes protected state.
ENGINEERING ENVIRONMENTS · FROZEN V1
Govern the execution environment without authorizing the environment itself.
An Engineering Environment is a first-class object with immutable identity. Its fingerprint, composition, lifecycle, health, readiness, evidence, drift, and relationships remain independent dimensions; only an Engineering Session can receive authorization.
Immutable identity and a governed inventory across native workstations, VMs, VDI, jump servers, RDP, and cloud engineering workspaces.
Administrator-controlled Discover, Learning, Under Review, Approved, Modified, Revalidation Required, Retired, and Archived transitions.
Independent health and readiness states distinguish Ready, Ready with Restrictions, Not Ready, and Unknown without creating authorization.
Expected and observed fingerprints remain separate; categorized drift preserves the exact evidence behind revalidation.
Level, Coverage, Freshness, Provenance, and Confidence remain independent and Unknown evidence remains Unknown.
References connect Engineer, Control Point, Application, Project, Controller, Permit, and Maintenance Window without duplicating authoritative state.
Discover→Learning→Under Review→Approved→Modified→Revalidation Required→Retired→Archived
Deterministic boundary: Every accepted lifecycle transition requires administrator authority, an explicit reason, and a work order. The transition and supporting evidence are fully audited.
Console workspace and API surface See the implemented views
Engineering Environments
Inventory and details expose lifecycle, health, readiness, enrollment progress, expected-versus-observed fingerprint, drift history, evidence, relationships, and audit history.
Environment summary
Lifecycle, health distribution, revalidation, readiness, recent drift, evidence coverage, and enrollment progress remain visible without duplicating EE state.
Read-only inventory
Engineering Environment inventory and details are available through EWSP.Read.v1. Lifecycle changes remain administrator-controlled Management operations.
Evidence rule
Unknown evidence remains Unknown. Decisions use explicit evidence and policy, never a risk score alone.
Execution coverageThe model supports native workstations, Hyper-V, VMware, VirtualBox, VDI, RDP, jump servers, cloud engineering workspaces, and future execution environments.
Backward compatibilityExisting deployments and Engineering Session evidence remain readable; sessions reference their associated Engineering Environment instead of copying its state.
PROTECTIONPOLICY V1
Availability is not a security outcome.
Authorization, explanation, and enforcement remain separate. One typed classifier prevents trust, evidence, controller, permit, project, signature, WFP, policy, or storage failures from being treated as system availability.
Decision→Failure Classification→ProtectionPolicy→Enforcement
Architecture rule: Only AvailabilityFailure may enter the ProtectionPolicy branch. Every other failure class remains a security or evidence outcome.
TrustFailureBlockA security outcome; never converted to availability.
EvidenceFailureUnknownCurrent behavior when required evidence cannot establish trust.
EnforcementFailureCritical FailureFailure to apply a decision is treated as critical.
StorageFailureEvidence gapBest-effort persistence plus recovery reconciliation.
AvailabilityFailurePolicy eligibleThe only failure class that may enter ProtectionPolicy.
Protection Mode
Deny new protected engineering activity when EWSP cannot evaluate or enforce. Existing behavior remains fail closed.
Availability Mode
Does not permit engineering activity. It records a protection-gap event and surfaces recovery reconciliation state; allow behavior is not implemented.
Operational boundary, exceptions, and recovery claims Learn more
EWSP governs new engineering access, not PLC runtime execution, SCADA or HMI behavior, physical-process safety, interlocks, or emergency shutdown.
Evidence without first-attempt protection
Engineering remains available while EWSP records why authorization is unverified.
Invalid new actions are denied
Protected communication is constrained; controller runtime remains outside EWSP’s scope.
Every exception is bounded
Maintenance permits require an authorized administrator, reason, exact application and destination scope, duration, expiration, and audit evidence.
Failure and recovery behavior must be testable. Crash recovery, permit expiry, reboot behavior, project modification, enforcement cleanup, backup restoration, and uninstall are acceptance-test evidence—not marketing assumptions. A broader emergency-override workflow remains future work.
CURRENT VALIDATION BUILD · EWSP v1.3.19
One Windows platform for governed engineering work from readiness through verified outcome.
The current source build preserves the frozen v1 object model while adding Engineering Work, Engineering History, engineering-data operations, metadata-only data references, Compliance & Governance projections, and Recovery & Operational Response. These views use existing sessions, evidence, audit, outcomes, and recovery without changing authorization behavior.
The Console opens around planned, active, blocked, failed, verification, recovery, change, and learned work using recorded Engineering Session evidence only.
Timeline, session history, replay, lessons, recovery, advisory references, and global search reconstruct governed work without manufacturing missing evidence.
Read-only coverage and governance summaries expose recorded authorization, readiness, evidence, verification, recovery, audit, and freshness boundaries.
Recorded evidence may support documentation relevant to IEC 62443, NERC CIP, FDA 21 CFR Part 11, or ISO 27001. EWSP does not claim compliance or certification.
A first-class inventory and workspace expose immutable identity, deterministic enrollment, lifecycle, health, readiness, fingerprint comparison, drift, evidence, relationships, and audit history.
Vendor Engineering Readiness Provider results are normalized into overall and per-component readiness evidence before Trust and Authorization. Siemens is the only v1 provider.
Each Engineering Session records a normalized operation such as PLC logic, drive parameters, firmware, HMI, safety, monitoring, diagnostics, backup, or recovery—without creating a new architecture object.
Pre-Flight evaluates the artifact, target identity, firmware, approval, rollback, or observe-only evidence required by the recorded operation. Unknown remains Unknown.
Authorization remains separate from operational success. Controller before/after evidence, faults, verification, recovery source, and version context are recorded only when observed.
Optional artifact-level readiness evidence distinguishes aligned, misaligned, incomplete, and unknown design context without replacing CAD, PDM, PLM, or vendor engineering tools.
Session-scoped evidence evaluates whether observed security prerequisites satisfy Engineering Session Policy. It does not monitor or diagnose infrastructure health.
Session-scoped application, dependency, catalog, license, and asset evidence is normalized without replacing vendor diagnostics.
Coverage, completeness, sufficiency, and decision confidence are reported independently, with a reason for every Not Evaluated item.
A generic contract preserves applicability, analysis mode, evidence quality, policy result, provenance, and provider boundaries across every readiness domain.
Typed failure classification precedes policy and enforcement. Availability Mode remains framework-only; Protection Mode continues to fail closed.
Installed by default with secure stdio transport. EWSP.Read.v1 fails closed and exposes no management or write operations.
Connected-client status, published tools and resources, version compatibility, diagnostics, and copy-ready MCP configuration.
Engineering Timeline and Case View connect trust, audit, session, project, permit, recovery, and candidate evidence.
Support Bundle packages diagnostics; Unified Evidence Export packages the evidence for one engineering event.
Recorded sessions drive timelines, readiness history, analytics, comparison, evidence confidence, decision replay, recovery history, lessons, and global search. Missing evidence is never inferred.
Import, export, tag, configuration, validation, transformation, synchronization, review, comparison, and deployment-preparation work remain governed Engineering Session attributes and evidence projections.
Sessions reference historian, SCADA, PLC trend, HMI, data-logger, and vendor-tool datasets using metadata only. EWSP does not ingest or duplicate historian samples.
Recorded outcomes, recovery evidence, session recommendations, timelines, and decision traces are projected from existing governed records. EWSP is not an incident-response platform.
Light, Dark, and System display modes apply app-wide with persisted selection, corrected dark-mode contrast, and consistent controls.
EVIDENCE AND VALIDATION
Demonstrated behavior, bounded claims.
In a two-machine test environment, one Windows system acts as the engineering workstation and another as the simulated industrial endpoint. EWSP learns permitted behavior, creates an approved policy, allows the authorized service, and blocks attempts when mandatory checks fail.
CONTROLLED RESULTALL SCOPED TESTS PASSEDAugust 2026
✓
Engineering Environment lifecycleDeterministic transitions require administrator authority, an explicit reason, and a work order. Identity remains immutable and accepted changes are persisted and audited.
✓
Engineering Session Pre-Flight v1Compatible results preserve the downstream authorization path; provider readiness failures produce NotStarted with component scope, provenance, recommendations, audit evidence, and Auditor exports.
✓
Engineering Operation TypeExplicit operations with missing required evidence produce NotStarted. Legacy sessions with no operation evidence remain Unknown and preserve existing behavior.
✓
Authorization and operational outcomeA permitted operation may still fail; a denied or NotStarted operation is NotPerformed. Audit, API, MCP, reporting, and exports preserve the distinction.
✓
Engineering Design ContextApplicable provider evidence is recorded per artifact. Misaligned, incomplete, or provider-unknown context produces NotStarted; no provider preserves existing behavior.
✓
Security Infrastructure ReadinessObserved facts, evaluated scope, session policy result, recommendation, and provider provenance remain separate. Unknown never passes.
✓
Engineering Readiness Framework v2A shared domain contract and Provider Capability Matrix disclose evaluation scope, limitations, evidence coverage, completeness, sufficiency, and confidence.
✓
Engineering Environment ReadinessApplicable provider results identify Ready, Missing Dependencies, Unsupported Environment, or Unknown; no provider preserves existing behavior.
✓
Evidence Domain reference providersDeterministic Behavior Verification and Interoperability fixtures validate the platform contract only; they do not parse vendor code, validate standards, or troubleshoot tools.
✓
Engineering HistoryTimeline, history, comparison, analytics, lessons, recovery, and decision replay use recorded evidence only and distinguish Observed, Not Evaluated, Not Recorded, and Unknown.
✓
Engineering governance projectionsEngineering Work Hub, Engineering History, Compliance & Governance, Standards Evidence Mapping, and Recovery & Operational Response add no authorization semantics or persistence model.
✓
Engineering data operationsArtifact identity, object counts, warnings, validation, verification, outcome, and recovery evidence are recorded without storing artifact contents or altering authorization.
✓
ProtectionPolicy failure boundaryTrust, evidence, enforcement, storage, and availability failures are classified before policy and enforcement; only AvailabilityFailure is policy-eligible.
✓
Native Windows WFP enforcementAuthorized service permitted; unknown service blocked on its first attempt.
✓
Continuous project-integrity controlSHA-256 baseline monitoring, access revocation, re-approval, and audit evidence.
✓
Scoped maintenance permitsApplication- and destination-specific exceptions with duration, reason, revocation, and expiry.
✓
Discovery-only application inventoryPath, publisher, signature, version, and SHA-256 evidence are recorded without creating approval or observation authority.
✓
Environment and artifact evidenceSupporting components and selected artifacts are Observed evidence; compatibility and tool provenance remain Unknown.
✓
Explainable environment snapshotsReadable manifests, individual hashes, canonical fingerprints, and exact component changes are preserved without blocking a session.
✓
Transport-neutral observationTCP and scoped UDP activity can be recorded with visible provenance and high-volume aggregation; observation never promotes trust.
✓
Hardened local managementRead-only and Management operations use separate local routes with Windows-token authorization, audit history, diagnostics, and offline enforcement.
Controlled technical validation is not plant-wide deployment or PLC-scale performance. Newer environment, artifact, snapshot, discovery, and network-observation capabilities are source-built and locally evidenced, but not yet installed and validated with a real OT engineering application, vendor artifact, controller, or second physical validation device. The current development package is unsigned.
Engineering Environment architecture Read the frozen v1 boundary
A first-class governed environment with evidence—not implied authorization.
EWSP records immutable Engineering Environment identity and keeps lifecycle, health, readiness, fingerprint, composition, evidence, drift, and relationships independent. Authorization belongs only to the associated Engineering Session.
Expected ≠ observed
Approved and observed fingerprints remain separate. Readable manifests and exact changes explain drift without guessing.
Unknown remains Unknown
Missing or unavailable evidence is never converted into a pass, an inferred fact, or a risk-score-only decision.
Evidence providers are not authorities
Connectors observe and contribute bounded evidence. The Protection Service remains the sole Control Point and policy authority.
InventoryEnrollmentLifecycleHealthReadinessFingerprintDriftEvidenceRelationships→Engineering Session reference
Current source capability
Deterministic lifecycle management, administrator-controlled transitions, environment inventory and Dashboard summary, readiness, expected-versus-observed fingerprints, categorized drift, evidence quality, relationships, audit history, and Read API support.
Architecture boundaryThe model governs native and virtual execution environments without replacing vendor engineering software, hypervisors, remote-access platforms, or infrastructure management.
Engineering Session Pre-Flight scope See the provider boundary
A normalized readiness model with vendor-owned engineering knowledge.
- EWSP evaluates engineering-session readiness by normalizing Vendor Engineering Readiness Provider results into a consistent readiness model.
- Vendor Engineering Readiness Providers own vendor-specific evaluations, recommendations, and compatibility logic.
- EWSP orchestrates Readiness, Trust, Authorization, Protection Policy, Enforcement, and Evidence.
- EWSP does not replace vendor engineering software, diagnostics, troubleshooting, or vulnerability management.
- Siemens is the only Vendor Engineering Readiness Provider implemented in v1.
Engineering Session Pre-Flight→Vendor Engineering Readiness Provider→Normalized Readiness Result→Trust and Authorization→Evidence
Engineering Operation Type See the session evidence boundary
Govern the requested operation without changing the frozen object model.
- Operation Type is an Engineering Session attribute—not a new architecture object.
- PLC logic, online edit, drive parameters, servo, HMI, safety, firmware, monitoring, diagnostics, backup, and recovery use the same session model.
- Pre-Flight reports required and missing project, parameter-set, target, firmware, approval, rollback, recovery, or observe-only evidence.
- Authorization and operational outcome remain independent: a permitted operation may fail, while a denied or NotStarted operation is NotPerformed.
- Controller timeline, version context, faults, verification, and recovery origin are recorded only when observed. Missing evidence remains Unknown or Not recorded.
Engineering Design Context See the artifact boundary
Available engineering artifacts become bounded readiness evidence.
- Applicable Vendor Engineering Readiness Providers evaluate only artifacts and scopes for which evidence is available.
- Each artifact retains its observed value, status, source, timestamp, provider provenance, confidence, scope, and recommendation.
- Aligned continues Pre-Flight. Misaligned, Incomplete, or provider-applicable Unknown produces NotStarted before Trust and Authorization.
- No applicable provider preserves existing behavior; Unknown never becomes Pass.
- EWSP does not replace CAD, PDM, PLM, design validation, vendor diagnostics, or engineering troubleshooting.
Security Infrastructure Readiness See the session boundary
Evaluate session prerequisites—not infrastructure health.
- Applicable Vendor Engineering Readiness Providers record only directly observed controller time, synchronization, certificate, trust-chain, and secure-communication evidence.
- Aligned, Incomplete, Degraded, and Unknown are normalized without inferring unavailable evidence. Unknown never becomes Pass.
- Evaluated and not-evaluated scope, Engineering Session Policy evaluation, recommendations, confidence, and provenance remain explicit.
- EWSP does not continuously monitor, diagnose, or manage enterprise PKI, certificate services, time synchronization infrastructure, or vendor engineering systems.
- Those responsibilities remain with Vendor Engineering Readiness Providers and OT security platforms.
Engineering Readiness Framework v2 See evidence-quality boundaries
Capability and evidence limits remain explicit.
- Every readiness domain uses the same normalized result contract.
- Coverage measures evaluation breadth; completeness measures artifact interpretation; sufficiency measures adequacy; confidence measures conclusion reliability.
- Every Not Evaluated item includes a structured reason.
- The Provider Capability Matrix lists supported domains, artifact classes, parser versions, limitations, and coverage/completeness capabilities.
- Successful provider execution does not imply complete understanding. Unknown, unsupported, skipped, unparsed, and failed content is disclosed separately.
Engineering Environment Readiness See the environment boundary
Evaluate the session environment—not troubleshoot it.
- Applicable providers evaluate observed application versions, required packages, libraries, catalogs, licenses, and project assets.
- Ready continues Pre-Flight. Missing Dependencies, Unsupported Environment, or provider-applicable Unknown produces NotStarted.
- No applicable provider preserves existing behavior.
- Observed facts, evaluated scope, assumptions, recommendations, evidence sources, and provider provenance remain separate.
- EWSP does not replace vendor engineering software, diagnostics, or troubleshooting.
Evidence Domain Framework v1 See the platform contract
New engineering disciplines integrate without changing Pre-Flight.
- Every Evidence Domain preserves applicability, observed facts, evaluated and not-evaluated items, unknowns, assumptions, analysis mode, scope, evidence quality, policy result, recommendation, sources, documentation, provider metadata, timestamp, and provenance.
- Not Applicable, Not Evaluated, and Unknown remain distinct. Policy ignores Not Applicable domains.
- Static Inspection, Runtime Observation, Hybrid, and Unknown remain explicit across Timeline, Auditor View, API, JSON, and PDF.
- Providers own bounded engineering interpretation and recommendations; EWSP owns normalization, orchestration, policy, persistence, explainability, and session governance.
- Behavior Verification and Interoperability are deterministic reference fixtures only—not AOI parsing, runtime instrumentation, standards validation, file repair, or vendor troubleshooting.
Evidence integrity and confidence Read the boundary
Compromise alone should not authorize a change.
EWSP assumes a workstation credential, remote-access path, or network segment may be compromised. Authorization still depends on the complete engineering context satisfying policy.
EVIDENCE, NOT JUST AN ALERT
Every decision should explain itself.
Records can preserve project hash, workstation and endpoint identity, requested scope, maintenance reason, time window, decision rationale, enforcement result, integrity state, and recovery evidence.
Evidence confidenceVerifiedObservedDeclaredInferredUnknown
The current release uses protected and tamper-resistant local evidence. It does not claim TPM-backed attestation, certificate-backed reports, or independently verifiable cryptographic timestamps.
Capability maturity See every capability
“Source build available” means implemented and locally tested but not yet packaged into the installed validation release. “Build available” means implemented in the current test release. “Lab validated” means exercised in EWSP’s controlled Windows environment. None means production-plant validation.
Operational readiness evidence See scoped test results
Protected backup creation, integrity validation, corrupted-backup rejection, controlled live restore, and rollback-copy creation.
10 service restart cycles and 100 authenticated Management API requests completed successfully.
Dynamic Windows Filtering Platform cleanup and restoration validated through controlled service transitions.
Configurable retention, controlled log rotation, diagnostic bundle, and alarm-history export containing 34 records.
Service configuration, automatic startup, recovery actions, local roles, data permissions, and installed components validated.
Release-package manifest and SHA-256 checksums verified for the validated test release.
This validates controlled Windows reliability and operational safeguards—not plant deployment, production code signing, real-controller validation, or every industrial vendor ecosystem. Version-specific release evidence is maintained separately.
Industrial identity provider coverage See available and planned providers
Protocol-specific identity is normalized into a common, protocol-independent Trust Engine model.
EWSP Simulator✓ AVAILABLE
EtherNet/IP (CIP)✓ BUILD AVAILABLE
Siemens S7PLANNED
OPC UAPLANNED
Modbus/TCPPLANNED
Vendor SDKsEXTENSIBLE
Current buildEWSP Simulator and EtherNet/IP (CIP) ListIdentity
Evidence boundaryCIP ListIdentity is direct protocol evidence classified High confidence, not cryptographic authentication. Real-controller validation remains pending.
Observation→Endpoint Identity Manager→Identity provider→Normalized identity→Trust Engine→Decision Engine→Native WFP enforcement
FUTURE SOC INTEGRATION DIRECTION
EWSP decides. Enterprise platforms retain and operationalize the record.
EWSP is the authoritative source for engineering-session authorization events. SIEM, SOAR, XDR, and OT security platforms remain systems of record for correlation, investigation, retention, and response.
Event API v1 roadmap and Sentinel scope View integration detail
Current source status
Event API v1 and the Microsoft Sentinel exporter are implemented in the source build. The affected Release build passes; ingestion into a configured Sentinel tenant remains pending validation.
EWSP authorization event→Integrity-protected Event API v1→Microsoft Sentinel→Future enterprise workflows
- EngineeringSessionApproved
- EngineeringSessionBlocked
- ProjectHashMismatch
- PermitViolation
- ProtectionServiceOffline
- ProtectionRestored
Decision, reason code, correlation and session IDs, engineer, workstation, engineering application, controller identity, project hash, baseline ID, permit status, maintenance window, evidence reference, and EWSP version. Trust score is optional.
Project contents are never exported.
First: Microsoft Sentinel through the Azure Monitor Logs Ingestion API.
Second: Splunk HEC.
ServiceNow: via established SIEM/SOAR workflows.
Future provider interfaces may support CEF, LEEF, Syslog, OpenTelemetry, QRadar, Elastic, Chronicle, and webhooks.
Roadmap boundary: Sentinel has a source implementation but tenant ingestion is not yet validated. All other named providers remain future direction and are not current product capabilities.
LOW-RISK ADOPTION
Begin with evidence. Add enforcement deliberately.
Discover sessions without blocking.
Approve assets, services, projects, and scope.
Protect chosen applications and destinations.
Measure workflow impact, recovery, and effectiveness.
Extend authoritative EWSP events into governed enterprise workflows.
2-MINUTE PRODUCT WALKTHROUGH
See an authorized session and a blocked one.
The walkthrough follows EWSP from Learning through approval, policy generation, first-attempt protection, and verified enforcement.
The recorded walkthrough shows an earlier interface. The current source direction centers Engineering Work, Engineering History, readiness, evidence, verification, recovery, lessons, governance projections, and secure read-only MCP access while preserving the frozen v1 authorization model.
▶ Play full-screenVALIDATION PILOT
Pressure-test the authorization boundary in a real engineering workflow.
EWSP is seeking experienced OT security leaders, industrial operators, automation vendors, and design partners.