EVOLV Security and Access Boundaries
EVOLV should expose central services, not field-edge systems, to external consumers.
Access Boundary
flowchart TD
EXT["External APIs / Enterprise Requests"] --> API["Central API Gateway"]
API --> AUTH["AuthN/AuthZ / Policy Checks"]
AUTH --> INTEL["Central Advisory / Decision Support"]
INTEL --> SITE["Site Integration Layer"]
SITE --> EDGE["Edge Runtime"]
EDGE --> PLC["PLC / Field Assets"]
EXT -. no direct access .-> EDGE
EXT -. no direct access .-> PLC
Principles
- External integrations terminate centrally.
- Central authenticates, authorizes, and mediates requests.
- Site and edge layers receive bounded requests, advice, or setpoints.
- Edge remains protected behind intermediate layers.
Purdue-Aligned Segmentation
EVOLV is designed to fit a Purdue-style industrial segmentation model:
- field and PLC assets remain at the lower operational layers
- edge runtimes sit close to the process and are not exposed as public integration surfaces
- site systems mediate plant-local services and isolate OT from broader enterprise traffic
- central services host APIs, identity, analytics, and engineering functions above the plant boundary
This matters because it gives a clear answer to external reviewers:
- EVOLV does not require direct enterprise-to-field access
- EVOLV can preserve layered trust boundaries between PLCs, edge runtimes, site services, and central platforms
- EVOLV can support zone/conduit style security designs instead of flattening OT and IT into one network
European Regulatory Positioning
EVOLV should be described as an architecture that can support compliance with strict European requirements, not as a system that is automatically compliant by default.
NIS2
Directive (EU) 2022/2555 (NIS2) requires cybersecurity risk-management measures and incident handling for important and essential entities.
This architecture supports that direction by:
- separating edge, site, and central responsibilities
- reducing direct exposure of operational assets
- allowing central policy, identity, logging, and oversight
- preserving local operation during upstream disruption
CER
Directive (EU) 2022/2557 (Critical Entities Resilience Directive) focuses on resilience of essential services.
This architecture supports CER-style resilience expectations by:
- keeping local and site operation viable during central outages
- enabling business-continuity and degraded-mode operation
- supporting multiple operational layers instead of one central dependency
Cyber Resilience Act
Regulation (EU) 2024/2847 (Cyber Resilience Act) sets horizontal cybersecurity requirements for products with digital elements.
Where EVOLV components are packaged, distributed, and maintained as digital products, the platform direction supports CRA-aligned engineering by:
- avoiding hard-coded secrets in tracked manifests
- treating updates, identity, security boundaries, and lifecycle management as platform concerns
- supporting traceable releases through central source control and CI/CD
GDPR
Regulation (EU) 2016/679 (GDPR) applies where EVOLV processes personal data.
The architecture helps support GDPR obligations by:
- centralizing external API ingress
- limiting unnecessary spread of sensitive data toward field layers
- enabling clearer control over access, logging, and retention boundaries
What We Can Defensibly Claim
The safe and accurate claim is:
- EVOLV can be deployed in a way that aligns with strict European cybersecurity and resilience expectations
- EVOLV can support Purdue-style layered OT/IT segmentation
- EVOLV can be engineered to satisfy strong governance, audit, and access-control requirements
The claim that should be avoided is:
- "EVOLV is automatically compliant"
Actual compliance still depends on:
- configuration
- site implementation
- monitoring and incident response
- supplier and patch management
- data-classification and retention policy
- documented operational controls
Why This Matters
- lower exposure of OT assets
- better separation between enterprise and plant networks
- easier enforcement of policy, logging, and audit controls
- safer long-term path for overview intelligence and API ecosystems
Operational Constraint
Central guidance should remain advisory-first. Local site and edge layers must still behave safely when central is degraded or unavailable.