Functional safety
E-stop, safety PLC, scanners, interlocks, safety-rated controllers and certified limits protect people and machinery from hazardous motion.
Remains authoritativeRobotics security / security layer
Cybersecurity for physical action.
Built to support compliance with new EU robotics cybersecurity requirements. →
TTAN.IO Robotics is a cross-layer cybersecurity and runtime-assurance layer for industrial robotics. It is designed to work alongside functional safety, robot-controller security, ROS / ROS 2, DDS Security, OT/CPS monitoring, endpoint protection, PKI, secure boot and vendor-native safeguards — while adding the governed boundary between digital intent and physical consequence. Its scope is broader than a single middleware, endpoint or network control because it connects identity and trust context, approved behavior, exact command authority, runtime verification, recovery and attributable evidence.
Built to support compliance with the EU Cyber Resilience Act, the Machinery Regulation and applicable AI Act / NIS2 obligations — while preserving the distinction between technical readiness and formal legal conformity or certification.
Coexistence rulePreserve every stronger control already in place.
TTAN.IO does not disable safety PLCs, E-stops, DDS permissions, ROS security enclaves, vendor ACLs, secure boot, endpoint hardening or network segmentation. Those controls remain authoritative in their own domains.
Layered by design
Each security layer keeps its job.
Robotics security fails when one control is asked to do everything. TTAN.IO deliberately separates identity, communications security, functional safety, endpoint trust and semantic physical-action governance.
ROS / DDS Security
Participant identity, signed governance and permissions, encryption, access control and secure enclaves protect middleware trust and communications.
Keep it enabledEndpoint / hardware trust
Secure boot, TPM/HSM roots, firmware signing, OS hardening, controller security and attestation protect the device and software stack.
Consume as trust evidenceOT / CPS security
Asset inventory, segmentation, vulnerability management, anomaly detection, threat monitoring and incident response protect the wider industrial environment.
Complement, do not replaceVendor controls
Native controller ACLs, API credentials, safety functions, lifecycle tools and secure update mechanisms remain part of the vendor trust boundary.
Preserve vendor guaranteesTTAN.IO Robotics
Validates mission semantics, approved behavior, current state, exact command binding, execution readiness, anti-replay, observation and recovery evidence.
Add the physical-action boundaryROS, ROS 2 and DDS
TTAN.IO does not compete with middleware security.
In ROS 2, DDS Security can provide authenticated identities, permission policies, signed governance, encrypted traffic and security enclaves. TTAN.IO treats those results as transport and participant trust evidence. It does not need to become the DDS Certificate Authority, rewrite governance files or weaken permissions.
Where a deployment uses ROS 1 or another robotics stack without equivalent native middleware security, TTAN.IO can still sit at a gateway or provider boundary while network segmentation, TLS tunnels, vendor controls or compensating protections continue to secure transport and access.
A DDS permission can say “this participant may call this action.” TTAN.IO asks the next question: “is this exact action, on this robot, with this tool, target, zone and current state, still admissible now?”
How the layer operates
Observe without authority. Govern dispatch only where explicitly integrated.
Observation-only
Telemetry, controller state, ROS/DDS observations, PLC state, sensors, vision and provider evidence can be collected without granting TTAN.IO any command authority.
Governed dispatch
When explicitly deployed inline, a command is normalized, evaluated against identity, baseline, policy and current state, then bound to the exact dispatch material before the existing provider interface is called.
Independent verification
After execution, TTAN.IO reconciles expected, requested, authorized, executed and observed state. A successful API response is not automatically accepted as physical success.
No hidden takeover.
Moving from observation-only to governed dispatch is a deployment decision. TTAN.IO should never silently intercept a production path, replace a safety controller, disable a middleware security policy or create new physical authority merely because connectivity exists.
What changes — and what does not
Security semantics are added above the existing trust stack.
| Existing control | What it already proves | What TTAN.IO adds | What TTAN.IO does not do |
|---|---|---|---|
| PKI / mTLS | Peer identity and authenticated channel | Uses identity as one input to robot/mission eligibility | Does not treat possession of a certificate as physical authority |
| ROS 2 / DDS Security | Participant identity, permissions, governance and encrypted middleware traffic | Semantic validation of the requested physical effect and exact command binding | Does not replace DDS access control or weaken enclaves/governance |
| Secure boot / hardware root | Trusted startup and component integrity evidence | Can use attestation/version state as an execution-readiness condition | Does not replace TPM/HSM/SoC trust roots or firmware verification |
| Functional safety | Hazard reduction, emergency stop and safety-rated limits | Cyber HOLD, HUMAN_REQUIRED, evidence and controlled security re-entry | Does not certify safe motion or replace safety-rated control |
| OT monitoring | Visibility, vulnerability and network/behavior anomaly detection | Per-robot mission authority and physical-action reconciliation | Does not replace the SOC, IDS, asset inventory or vulnerability program |
| Vendor controller security | Native permissions, limits, update and device protections | Provider-neutral validation before privileged command use | Does not bypass or weaken vendor security controls |
Physical-action governance
The exact command is the unit of authority.
TTAN.IO does not authorize a generic session and then assume every later command is acceptable. Authority is designed to remain bound to the robot, mission, provider path, approved baseline, normalized command, nonce and bounded validity context.
01Identity + provenance
Establish who or what is asking and where the request came from. Identity becomes trusted context — never automatic physical authority.
Read how it works → 02Robot + baselineBind the request to the exact robot, toolset, capabilities, zones and approved behavior. Runtime drift does not silently become the new truth.
Read how it works → 03Mission validationNormalize the requested action and evaluate its physical meaning against capability, policy, target, zone, tool and production context.
Read how it works → 04Execution readinessRe-check whether the mission is admissible now. Current state, provider path, replay state and security preconditions must still be valid.
Read how it works → 05Exact command bindingBind authority to the command that will actually be sent. Changing a robot, target, tool, zone, limit or parameter invalidates old authority.
Read how it works → 06Observed outcomeCompare authorized intent with controller, ROS, PLC, sensor and provider evidence. A successful API response is not physical truth by itself.
Read how it works →Changing the robot, tool, target, zone, destination, provider path, action or security-relevant limit changes the command context. Old authority should not silently follow the modified action. Replay, reconnect, failover and recovery are treated as fresh security events rather than reasons to widen trust.
Human-first recovery
Cyber recovery is not automatic physical restart.
TTAN.IO separates containment from return to service. A HOLD can stop cybersecurity eligibility, but removing that HOLD is not enough to prove that the real cell is ready to move again.
The physical world may have changed while software was being restored: a part may still be held, another robot may have moved, a conveyor may have advanced or a tool may be in a different pose. Recovery therefore requires fresh evidence and, where policy requires it, real human approval.
Recovery restores eligibility. It never resurrects old authority.
European Union — legal context
Cybersecurity is becoming a product requirement, not an optional add-on.
There is no single “EU Robot Cybersecurity Act.” Robotics can sit at the intersection of product cybersecurity, machinery safety, AI regulation and entity-level cybersecurity law. Which obligations apply depends on the robot, its intended use, how it is placed on the EU market and who operates it.
11 September 2026
Cyber Resilience Act reporting
Reporting obligations for actively exploited vulnerabilities and severe incidents affecting products with digital elements begin on this date. Early warning and follow-up deadlines are part of the CRA reporting regime.
Official EU guidance →20 January 2027
EU Machinery Regulation
Regulation (EU) 2023/1230 becomes applicable. Annex III includes “protection against corruption” requirements for connected machinery, critical software/data and evidence of legitimate or illegitimate intervention.
EUR-Lex →11 December 2027
CRA main obligations
The Cyber Resilience Act’s main product-security obligations apply. Manufacturers of in-scope products with digital elements must address security by design, risk assessment, vulnerability handling, support periods, documentation and conformity obligations.
Official EU summary →AI Act — phased
AI where applicable
The AI Act is already generally applicable, but high-risk requirements are phased. Not every AI-enabled robot is automatically high-risk. AI used as a safety component of regulated machinery can trigger additional obligations under the Act’s product-safety route.
EUR-Lex →As of September 2026:
The CRA’s main product-security obligations are not yet fully applicable, but the vulnerability/severe-incident reporting start date is imminent on 11 September 2026. The Machinery Regulation becomes applicable in January 2027. Organisations may also already be subject to NIS2 through national law depending on sector, size and Member State implementation.
How TTAN.IO can support regulatory readiness
Evidence-oriented controls map well to emerging obligations.
Protection against corruption
Approved baselines, exact command binding, anti-replay and controlled change help detect or reject unauthorized modification of security-relevant robot behavior.
Evidence of intervention
Identity, request, approval, baseline, dispatch, observation, deviation and recovery evidence can preserve an attributable record of legitimate and illegitimate intervention.
Secure lifecycle
Version and provenance state can be incorporated into readiness decisions, while vendor secure-boot, patching and update mechanisms remain authoritative for the underlying product.
Incident reconstruction
Multi-source telemetry and evidence reconciliation can reduce ambiguity when determining what was requested, what executed and what physical effect was observed.
Human oversight
HUMAN_REQUIRED and explicit approval boundaries support human-first governance where risk, policy or applicable AI obligations require human intervention.
Audit without false certification
TTAN.IO can produce structured cybersecurity evidence, but deployment of TTAN.IO does not by itself certify a robot under the CRA, Machinery Regulation, AI Act, ISO 10218 or IEC 62443.
Standards and frameworks
Law, standards and technical controls are different things.
ISO 10218-1:2025 and ISO 10218-2:2025 address industrial robot safety and robot applications/cells. They are important safety standards, not a substitute for cybersecurity law. TTAN.IO is designed to coexist with their safety model rather than claim to replace it.
IEC 62443 remains highly relevant to industrial cybersecurity architecture, zones/conduits, secure development and component/system security. DDS Security and ROS 2 security remain relevant to authenticated and authorized middleware communications.
NIS2 is primarily an entity-level cybersecurity regime. Medium and large organisations in covered sectors — including certain manufacturing categories — can be subject to risk-management and incident-reporting duties through Member State law. It is not a product certification for an individual robot.
Broader cybersecurity coverage
One layer connects controls that are usually evaluated separately.
Cross-layer coverage
Identity, transport trust, approved behavior, exact command authority, runtime state, observation, recovery and evidence are evaluated as one robotics-security chain rather than isolated controls.
AI optional
TTAN.IO is robotics cybersecurity, not an AI control product. The same boundary works for HMI, MES, PLC and traditional robot programs; when AI exists, it can recommend without becoming physical authority.
Vendor neutral
Security meaning remains stable even when the transport, robot vendor, middleware or provider adapter changes.
Small to large
Start with one cell or five robots and preserve the same per-robot identity, baseline and evidence model as the operation grows.
Regulatory-readiness evidence
Operational decisions remain reconstructable for incident response, audit, governance and readiness work around CRA, Machinery Regulation and other applicable EU obligations.
Fail closed without false safety claims
Unknown, ambiguous or conflicting cybersecurity state can stop dispatch eligibility without pretending TTAN.IO has replaced certified functional safety.
Current product boundary
Transparent about what TTAN.IO Robotics is today.
TTAN.IO Robotics currently has a closed Phase 1 software/security foundation and an active Phase 2 laboratory/provider-evidence program. It is not yet safety-certified, production-authorized or claiming real physical-production authority. The public architecture is intentionally separated from future physical activation.
Compliance support is not legal certification.
The controls described here can support security engineering, evidence and regulatory readiness. Actual CRA, Machinery Regulation, AI Act, NIS2, ISO or IEC conformity depends on the product, deployment, economic operator role, Member State implementation where relevant, conformity assessment and independent legal/safety analysis.