Bently Nevada publishes two different IEC/ISA-62443 statements about Orbit 60, and they are not interchangeable. The Q1 2021 Orbit article says that, where possible, Orbit 60 was designed to meet Security Level 4, the highest level of the standard. The December 2021 data-security article says the system “is being certified to IEC 62443-4-2 Security Level (SL) 2 and is architected to achieve up to Security Level (SL) 4”. The current datasheets carry no security level number at all: they say only “Designed to meet IEC 62443-4-2”. SL4 is therefore an architecture target, SL2 is the certification target, and neither statement is a certificate in hand.
By TenBN Editorial Team · Updated November 3, 2026 · 14 minute read
Quick answer
Orbit 60’s cybersecurity story is real, but the headline number is not a compliance claim you can paste into a 62443 gap analysis. Three points decide what the platform actually buys you.
First, the security level that matters for a component is SL-C: the capability the component can provide when it is configured correctly. SL-C is tested and, optionally, certified; “architected to achieve” is a design statement about headroom, not a test result. Second, the patented aXess path segregates one specific boundary: protection functions from condition monitoring functions inside the same rack. It does not segregate the condition monitoring port from your business network, and the Communications Gateway is bidirectional by design. Third, the useful question for a specifier is not “is it SL4?” but “what SL-C does each module claim, what is the certificate scope, and which network is each module allowed to touch?”
If you are standardising on Orbit 60, ask for the per-module SL-C claim and the certificate identifier. If you are running a 3500 machinery protection system, none of this changes your obligations: on the older platform the segregation work sits entirely in your network design, which is the subject of our 3500 support status and Orbit 60 comparison.
The three vendor statements, and what each one commits to
Bently Nevada’s own material contains three distinct claims about Orbit 60 and IEC/ISA-62443. They were written for different audiences, and they carry different weight in an audit.
| Statement | Source | What it commits to | What it does not say |
|---|---|---|---|
| “Where possible, we have designed Orbit 60 to meet Security Level 4 (the highest level) of the IEC/ISA-62443 Standard” | Orbit 60 Series Update: Cyber Secure Condition Monitoring!, Q1 2021 | Design intent, with an explicit hedge: “where possible” | Which modules, which requirement vector, and against which tested level |
| “The Orbit 60 is being certified to IEC 62443-4-2 Security Level (SL) 2 and is architected to achieve up to Security Level (SL) 4” | Orbit 60: a data secure condition monitoring system, 21 December 2021 | A named certification target (SL2) plus a separate architecture ceiling (SL4) | That certification completed; “is being certified” is a process statement |
| “Designed to meet IEC 62443-4-2” / “Aligned to the IEC 62443-4-2 standard” | System datasheet 137M5182, CMM datasheet 145M9028 Rev. D, PPM datasheet 142M8515 | Alignment with the component technical-requirements standard | No security level number appears in the datasheets at all |
Read in sequence, the three statements narrow rather than contradict each other. The 2021 newsletter is the most expansive, the December 2021 blog is the most precise, and the datasheets are the documents a purchaser will actually be held to. When the marketing and the datasheet differ, the datasheet is the one that ends up in the bill of materials.
SL-T, SL-C, SL-I, SL-A: the vocabulary that decides whether a claim is testable
Most confusion about Orbit 60 and 62443 is vocabulary failure, not engineering failure. IEC 62443 uses the phrase “security level” for five different things, and only one of them applies to a device you buy.
| Term | Applies to | Set by | Verifiable as |
|---|---|---|---|
| SL-T (target) | A zone or conduit in a system | The asset owner, from risk assessment | A line in your security requirements specification |
| SL-C (capability) | A component, per IEC 62443-4-2 | The manufacturer, then a test lab | A test report or certificate with a stated scope |
| SL-I (implemented) | A system as configured | The integrator | Configuration evidence against the 62443-3-3 requirement matrix |
| SL-A (achieved) | A system after assessment | An assessor | A 62443-2-4 or -3-3 assessment report |
| ML (maturity level) | The developer’s process, per 62443-4-1 | The manufacturer, then an auditor | A secure development lifecycle audit |
“Architected to achieve up to SL4” is a statement about SL-C headroom. It says the design could, in principle, meet the SL4 requirement vector. It does not say the requirement vector was tested, that a lab agreed, or that the certificate exists. Both halves of the standard’s component side matter here: 62443-4-1 governs how the product was developed, 62443-4-2 governs what the product technically does, and the two are certified separately.
The standard also splits components into four types: embedded devices, host devices, network devices and software applications. Each type has its own requirement set, so an SL-C claim without a component type is not comparable between vendors. Orbit 60 spans at least two of them: the protection and monitoring hardware is an embedded device, and Orbit Studio plus the System 1 interface are software.
What the four security levels actually defend against
IEC 62443-1-3 defines the levels by the adversary they assume, not by a feature count. That is the honest way to judge whether “the highest level” means anything for a vibration monitor in a control room.
| Level | Threat model in the standard’s words | What it means for a protection rack |
|---|---|---|
| SL1 | Protection against causal or coincidental violation | Covers mistakes: a wrong cable, an unplugged laptop, a fat-fingered setpoint change |
| SL2 | Intentional violation using simple means with low resources, generic skills and low motivation | Covers opportunistic scanning, default credentials and commodity malware reaching the control room |
| SL3 | Intentional violation using sophisticated means with moderate resources, IACS-specific skills and moderate motivation | Covers an attacker who has read the protocol documentation and is targeting your process |
| SL4 | Intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation | Covers a well-funded, persistent, targeted campaign against this equipment class |
The popular gloss that SL4 means “nation-state attackers” comes from threat-actor commentary rather than the normative text, and it is a useful sanity check on how far a design statement is from a certificate: the requirement vector at SL3 and SL4 pushes authentication and key protection into hardware, and demands multi-factor authentication across all networks rather than only untrusted ones.
For context on how rare these certificates are, SL2 certification against 62443-4-2 is still press-release material in 2026: KUKA announced the first robotics manufacturer to hold an SL2 certificate under that standard in July 2026, and ARC Informatique announced an SL2 certificate for PcVue 17 in April 2026. A machinery protection rack holding a third-party SL4 certificate would be a first for the category. We could not find a published 62443 certificate for Orbit 60 in any registry, on the vendor’s product page, or in its datasheets as of this writing.
What aXess actually segregates
The aXess claim is the most substantive part of Orbit 60’s security story, and it is a hardware claim rather than a configuration claim. From the Orbit 60 brochure:
“We call it Orbit aXess technology. It allows the protection and condition monitoring functions to coexist in the same rack and use the same I/O, yet function completely independent of one another. The protection components are able to publish their data for consumption by the condition monitoring system, but without any physical circuit board traces that allow the data to move from the condition monitoring components back to the protection components. The data moves one direction, and one direction only, without any digital handshaking. It’s like a diode—only better. And, it’s patented.”
Three properties make that worth specifying. The barrier is a printed circuit board trace layout, so it cannot be misconfigured the way a firewall rule can. There is no digital handshake, so there is no protocol stack on the protection side listening for a return message. And because the two functions share the same I/O, the segregation does not require a second set of sensors or a second wiring run, which is where conventional protection-plus-monitoring architectures leak.
The vendor is also explicit that this is not a conventional data diode, and the reason matters: “Data diodes are highly effective because they preclude any inbound communications, allowing only outbound. This one-directional design comes at a price, however: it means that on-the-fly changes to the condition monitoring system cannot be done. Thus, while protecting the protection system from intrusion, they also prevent the condition monitoring functions from being accessed. Our aXess technology enables segregation between the protection system and the condition monitoring functions—not between the condition monitoring functions and the outside world.”
Three boundaries, and only one of them is the diode
This is the section to read before you write “built-in data diode” into a compliance matrix. Orbit 60 has at least three distinct network boundaries, and the marketing sentence describes exactly one of them.
| Boundary | Module involved | Direction | Reachable from | What still belongs to you |
|---|---|---|---|---|
| Protection to condition monitoring, inside the rack | aXess path between protection components and the CMM | One way, no digital handshaking, enforced by trace layout | Not addressable from the monitoring side | Nothing: this is a hardware property of the platform |
| Condition monitoring to business network | CMM, through a cyber-secure access port with two independently configurable RJ-45 Ethernet ports | Two way: System 1 can configure what the CMM extracts | The L4 business network, per the vendor’s own wording | Segmentation, access control lists, host hardening, credentials and monitoring |
| Process control to the rack | Communications Gateway (CGW) | Two way by design: sends data, status and setpoints; receives controls such as inhibit, reset and trip multiply | Control network, DCS and historian | Firewall or DMZ policy, authorisation of the control path, change management |
| Engineering and configuration access | System Interface Module (SIM) and Orbit Studio, with TLS-encrypted communications | Two way | Engineering and control room networks | Multi-factor authentication, role separation, firmware provenance and patching |
A plant that reads “built-in data diode” as covering the second and third rows has mistaken a design property for a network architecture. The CMM is designed to be reachable from the business network: that is the point of it, and it is why Orbit 60 can drop the separate condition monitoring gateway that a wired 3500 plant needs, such as a 3500/92 communication gateway sitting between the rack and the historian. The CGW is designed to accept control commands. Both are legitimate designs; neither is a diode.
The practical consequence is favourable, though. Because the one-way property is at boundary one, the protection function keeps its integrity even when the condition monitoring side is fully reachable and fully configurable. You can run the monitoring port on a normal OT VLAN without weakening the trip path, which is the trade-off that conventional diode deployments get wrong.
Multiple CMMs, and what the datasheet supports
The Condition Monitoring Module is the module that carries the aXess data into the business network, and it is deliberately not a protection device. From the CMM datasheet (145M9028 Rev. D): “It only listens, with no capability to write, allowing interface to System 1 over the business networks, with no risk to the protection system.”
That sentence is often quoted as though it meant the CMM is read-only for everyone. It does not. “No capability to write” describes the backplane relationship: the CMM cannot write into the protection path. System 1 can still configure the CMM itself, because “System 1 can configure the CMM module to extract additional measurements and waveforms from system sensor data.” The read-only guarantee is directional, not absolute.
On count and placement, the datasheet is specific: each module occupies one slot, and “Placing multiple CMM modules allows the connection of two independent System 1 clients to the Bently Nevada Orbit 60 System.” The brochure adds the reason to install more than one: use multiple CMMs for additional processing power. Each module also provides two independently configurable Ethernet ports, and non-volatile storage buffers historical data when the link to the host is lost, which is what keeps a flaky business-network path from becoming a data-integrity problem.
| Module | Role | Network domain it touches | Safety status |
|---|---|---|---|
| SIM (System Interface Module) | One SIM defines a system of up to 64 dynamic channels and is the access point for configuring and maintaining it | Engineering and configuration path | Aligned to IEC 62443-4-2, TLS-encrypted communications; a key-lock switch and a utility-side contact physically secure the configuration |
| PPM (Protection Processor Module) | Protection computation; recommended in redundant pairs | Protection side only | SIL 2 option; SIL 3 capable per the vendor’s safety material |
| CMM (Condition Monitoring Module) | Listens to the backplane and serves System 1 | Business network, through the cyber-secure access port | Explicitly non-SIL: non-interfering with the safety system |
| CGW (Communications Gateway) | Exchanges data, status and setpoints; receives inhibit, reset and trip-multiply commands | Control network and historian | Part of the control path, so treat as a control-system node |
| BRG (Bridge Module) | Links chassis, including distributed runs | Intra-system | Extends the same segregation across chassis |
| ISM (Integrated System Module) | Replaces separate SIM, PPM and CGW functions in one slot: system interface plus protection processing plus industrial communication | Configuration, protection and communication paths | Aligned to IEC 62443-4-2 per its datasheet |
The CMM’s own datasheet states the safety position plainly: “This component is non-interfering with the safety system. The system SIL 2 certification does not require this component be SIL certified.” That is a useful asymmetry: the monitoring path is where the connectivity lives, and it is deliberately outside the certified safety function. The same separation of concerns is what lets a wireless sensor such as the Ranger Pro feed trending data without touching a trip path at all.
One control inside the box deserves more attention than it usually gets. The SIM carries a key-lock switch on the public side and a contact on the utility side, and either one can be used to secure the system configuration and prevent unauthorized changes. In 62443 terms that is a physical protection control on the configuration path, implemented in hardware, and it is the kind of thing that survives a network compromise. If your procedure is to leave it in the unlocked position permanently, the control is worth nothing; put its state in the shift-handover checklist.
What an auditor can verify, and what to ask the vendor to send
Every claim in the previous sections is a design statement. The following list is what converts it into evidence, and it is the difference between a compliant specification and a brochure.
| Ask for | Why it matters | Acceptable evidence |
|---|---|---|
| Per-module SL-C claim | Security levels are component claims, not product-family claims | A statement naming the module, the component type and the requirement vector |
| Certificate identifier, issuing body, scope and expiry | Design statements and certificates are different documents | A certificate you can look up with the lab, not a datasheet sentence |
| 62443-4-1 maturity level | Process assurance explains how firmware defects get found before you do | Audit reference for the development lifecycle |
| Hardening guide and default configuration | SL-C assumes correct configuration; defaults rarely are | A document listing disabled services, open ports and default accounts |
| Port and service inventory per module | The CMM’s two RJ-45 ports are physical attack surface in a control room | Documented services per network port |
| Software bill of materials and patch advisory feed | 62443-2-4 maintenance obligations run for the life of the rack | SBOM plus a subscription to advisories |
| Which networks each module is designed to touch | Zone and conduit design depends on it | An architecture drawing distinguishing CMM, CGW and SIM paths |
Ask the last question early. The distinction between the condition monitoring port and the control gateway is the one that most often gets lost between a bid sheet and a commissioning drawing, and it is the one that determines whether your protection network is genuinely separated from your historian.
What the plant still owns
Orbit 60 removes work from your design; it does not remove responsibility. Four items stay with the asset owner even on a platform architected to SL4.
Zone and conduit design. IEC 62443-3-2 assigns zones by data criticality and threat, and conduits by how data crosses between them. A rack is a component inside a zone, not a substitute for the model. The CGW is a conduit that carries control commands, and it needs the same treatment as any other control-system link.
The “where possible” exceptions. The vendor’s own hedge is an admission that some requirement vectors are not met everywhere. Those exceptions are not published. Find them on your instance: test whether the CMM’s Ethernet ports accept an unauthorised host, whether unused services are closed, and whether configuration changes on the monitoring side produce an audit record.
Identity and access on the monitoring path. Because System 1 can reconfigure the CMM, credentials on the business network decide who can change what a machine’s data looks like. That does not trip a machine, but it can hide a developing fault, which is the failure mode that matters in a protection programme.
Physical access. A control room rack with two live Ethernet ports per monitoring module is a different exposure from the same rack inside a locked, segmented enclosure. The aXess design protects the trip path from that port; it does not protect your data or your historian from it.
Where this leaves a 3500 plant
The 3500 platform predates the 62443-4-2 component standard, so its security posture is entirely a function of how you build the network around it. That is a manageable position, not a defect, and it is why long-term support planning and network design have to be done together. Our 3500 PCBA refresh and long-term support article covers the hardware side, and the support status comparison covers which platform to standardise on.
On a 3500 rack, the equivalents of Orbit 60’s boundaries are devices you place yourself: a 3500/92 communication gateway at the network edge, a 3500/20 rack interface module carrying the backplane data, a 3500/22M transient data interface if you need waveform capture off the rack, and a 3500/32 relay module where trip outputs must be hardwired. The 3500/05 system rack and 3500/15 power supply complete the chassis.
Sensor-side, the same transducers feed both platforms, which is the practical argument for not rushing a migration: a 3300 XL 8 mm proximity probe, a 330400 accelerometer or a 330500 Velomitor does not become a security liability when the rack behind it changes. For smaller assets, a 1900/65A or a 2300/20 monitor gives you a defensible network footprint without a full rack, and wind assets have their own path in the 60M100 condition monitor.
Where the platform choice is really an application question, our guides to gas turbine monitoring, steam turbine monitoring, compressor condition monitoring and petrochemical machinery protection set out what protection segregation buys in each case, and the 3500 series overview documents the older architecture in the same terms.
Purchase-order language that survives scrutiny
If you are specifying Orbit 60 into a facility with an IEC 62443 programme, three sentences keep the vendor’s claims and your obligations in the right places.
“The supplier shall state the claimed IEC 62443-4-2 security capability level (SL-C) for each module in the offered configuration, together with the component type classification used. A statement that the product is designed or architected to a security level shall not be accepted in place of a per-module SL-C claim.”
“Where a third-party 62443-4-2 certificate exists for any offered module, the supplier shall provide the certificate identifier, issuing body, scope and expiry date. Absence of a certificate shall be stated explicitly rather than inferred.”
“Segregation between machinery protection and condition monitoring functions within the rack shall not be treated as a substitute for the buyer’s zone and conduit design. All bidirectional paths, including the communications gateway to the control network and historian, shall be documented as conduits and protected accordingly.”
Those three lines also work as a due-diligence test for competing platforms, because most of them cannot answer the first one.
FAQ
Is Orbit 60 certified to IEC 62443 Security Level 4?
No published certificate says so. Bently Nevada states that Orbit 60 was designed, where possible, to meet Security Level 4, and in December 2021 that the system was being certified to IEC 62443-4-2 Security Level 2 while being architected to achieve up to Level 4. The current datasheets say only that the platform is designed to meet IEC 62443-4-2, with no level number. Treat SL4 as a design target and SL2 as the certification target until a certificate identifier is provided.
What does the Orbit 60 data diode actually protect?
One boundary: the path from the condition monitoring functions back into the protection functions inside the same rack. The aXess design omits the circuit board traces that would let data travel that way and uses no digital handshaking, so the protection path cannot be reached from the monitoring side. It does not isolate the condition monitoring port from your business network.
Does aXess replace a firewall between Orbit 60 and the plant network?
No. aXess segregates protection from condition monitoring within the rack. The Condition Monitoring Module is designed to connect to the business network, and the Communications Gateway exchanges data, status and setpoints with control systems and historians while receiving commands such as inhibit, reset and trip multiply. Those two paths still need your zone and conduit design.
Can more than one CMM be installed in an Orbit 60 system?
Yes. Each Condition Monitoring Module occupies one slot, and the datasheet states that placing multiple CMM modules allows the connection of two independent System 1 clients. The brochure adds that multiple CMMs can be used for additional processing power, and each module provides two independently configurable Ethernet ports.
Is the Condition Monitoring Module part of the safety function?
No. Its datasheet states that the component is non-interfering with the safety system and that the system SIL 2 certification does not require the CMM to be SIL certified. It listens to the backplane and serves System 1, and it has no capability to write into the protection path.
What is the difference between SL-C, SL-T and SL-A?
SL-C is the capability level a component claims under IEC 62443-4-2 when it is configured correctly. SL-T is the target level an asset owner sets for a zone or conduit. SL-A is the level actually achieved by a deployed system after assessment. A component certificate says nothing about the achieved level of your system, which depends on configuration and network design.
Does Security Level 4 mean protection against nation-state attackers?
That phrasing comes from commentary on threat actors, not from the normative definition. IEC 62443-1-3 defines SL4 as protection against intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation. In practice it pushes authentication and key protection into hardware and expects multi-factor authentication across all networks.
We run a 3500 system. Does any of this change our obligations?
Not directly. The 3500 platform predates the 62443-4-2 component standard, so segregation, filtering and access control are implemented in your network design rather than inside the rack. The practical work is documenting which node crosses from the control network to the rack, usually a communication gateway, and hardening that path.
Related reading
Orbit 60 fact sheet: 100× processing, 65 channels and half the footprint — what the 2025 fact sheet claims and where it disagrees with the system datasheet.
Orbit 60 Q4 update: 80 input card types cut to 10 — the module and spare-parts reading of the same platform, including the CGW, CMM and bridge output path.
Cordant devices: what the Bently Nevada homepage change means for buyers — who supports this hardware and what to check before ordering spares.
Bently Nevada System 1 at 20 years — the host software on the other end of the CMM port.
Bently Nevada’s AI machine health service — what happens to condition monitoring data once it leaves the rack.
Sources and method
This article reads Bently Nevada’s own statements against the structure of the standard they cite, and states the gaps rather than smoothing them. Vendor material is quoted as vendor material.
Bently Nevada, “Orbit 60 Series Update: Cyber Secure Condition Monitoring!”, Q1 2021. Bently Nevada, “Orbit 60: a data secure condition monitoring system”, 21 December 2021. Bently Nevada, Orbit 60 Series product page. Bently Nevada, Orbit 60 Series brochure (document 1312). Bently Nevada, Orbit 60 Series System Datasheet 137M5182. Bently Nevada, Orbit 60 Series Condition Monitoring Module Datasheet 145M9028 Rev. D. Bently Nevada, Orbit 60 Series Protection Processor Module Datasheet 142M8515. Baker Hughes press release, “BHGE’s Bently Nevada business launches the Orbit 60 Series”, 10 September 2019. IEC 62443-1-3 security level definitions and the SL-T, SL-C, SL-I and SL-A distinctions. KUKA, “First in robotics to achieve Security Level 2 certification in accordance with IEC 62443-4-2”, July 2026. ARC Informatique, PcVue 17 IEC 62443-4-2 SL2 certificate announcement, April 2026.
Editorial note: security level claims, certification status and module scope should be confirmed against the current datasheet revision and the vendor’s certificate documentation before they are written into a compliance matrix or a purchase order. We found no published third-party 62443 certificate for Orbit 60 as at 3 November 2026; if one has since been issued, the certification target and scope will differ from what is described here.
