FAQ

FireBreak™ is a physical Layer 1 network isolation appliance. Unlike software-based security tools — firewalls, EDR, and SIEM — it does not detect, analyze, or block threats. It physically disconnects network segments at the cable level, making assets invisible and unreachable. No software can override it, and no compromised credential can bypass it.

Software segmentation — VLANs, firewalls, and zero-trust policies — operates on the same physical layer as the attacker. If credentials are compromised or a configuration error exists, the protection fails. FireBreak™ removes the network path entirely. There is nothing to exploit because there is no connection.

Organizations managing upwards of 80 security tools across 30+ vendors often find that complexity itself becomes a vulnerability — fragmented visibility, alert fatigue, and configuration gaps that attackers actively probe. FireBreak™ is not a replacement for your stack. It is the last line of defense that operates independently of it: a physical control that works even when your software controls have been defeated.

Deep segmentation means enforcing isolation at the physical connection layer, not just the logical one. Rather than tagging traffic or applying policy rules, FireBreak™ severs the physical path between segments — OT from IT, backup from production, and third-party access from the core network — on demand and in seconds. It is segmentation you can verify by looking at the cable, not just by trusting a software rule.

FireBreak™ is controlled via non-IP mechanisms — SMS or a dedicated out-of-band management interface — meaning the control channel is completely separate from the network being protected. An attacker who has compromised your primary network cannot reach or influence the FireBreak™ control plane. This is a foundational design principle, not a feature.

Three: the 12-port RJ45 Ethernet appliance (1U rackmount), and two SFP optical variants (R1200 and S1200). RJ45 throughput is up to 10 Gbps per port pair; optical variants support up to 25 Gbps. All are hardware-agnostic and integrate into any standard network.

It replaces a single LAN or optical cable segment at a key point in the network. The existing cable is moved to the FireBreak™’s upper port, and a second cable connects the lower port to the original endpoint. The FireBreak™ now sits inline — the functional equivalent of a managed patch cable. Physical mounting typically takes minutes; control interface configuration can take anywhere from a few minutes to a couple of hours depending on complexity.

Most teams allocate 15 minutes to 2 hours. The primary steps are physical mounting, power connection, and cabling — the unit ships ready to use. Control interface and user provisioning are the variables: straightforward deployments are completed in under 30 minutes, while complex multi-port configurations with role assignments and OTP provisioning may take longer.

None of the above. It is a Layer 1 device — the network equivalent of a managed patch cable. It has no IP address on the protected path, no MAC address table, and no routing logic. Traffic either flows or it does not, based solely on whether the physical relay is closed or open.

CE, UKCA, CISPR 22/32, FCC Part 15B Class A.

RJ45 variants have dual power supplies for resilience. Each port can be configured to one of three fail states: fail-open (connected), fail-closed (disconnected), or return to the last known state. Optical variants go dark on power loss, meaning connectivity drops. In all cases, the fail behavior is preconfigured and predictable, not random.

Yes. It operates at Layer 1 regardless of the protocol, device type, or traffic above it. It protects Ethernet networks, SCADA systems, PLCs, industrial control systems, BMS infrastructure, and fiber-connected assets equally. No device on the protected segment needs to be modified or aware of the FireBreak™.

There are two roles. Administrators configure the appliance, provision users, set port permissions, and manage OTP seed keys — exclusively via the rear Management Port (ensuring physical separation of duties). Users are authorized to send connect/disconnect commands to assigned ports via the secure messaging stack. Users have no access to the Management Port.

Enable port [1–12], Disable port [1–12], and Status port [1–12]. All commands require challenge/response authentication and are case-sensitive. The full command set is documented in the Administration Guide.

The SMS interface rejects all messages by default. To authorize a user:

1. Whitelist their mobile number
2. Assign specific port permissions
3. Generate a unique OTP seed key compatible with Google Authenticator, Microsoft Authenticator, or Cisco Duo

Every command must include a valid OTP. Failure to meet any of the three criteria results in rejection.

Via the rear Management Console Port. Connect it to a dedicated management network and access the device’s IP address through a browser. Security aligns with NIST 800-63 requirements, including two-factor authentication, brute-force protection, and full audit logging.

This is a common concern and, in practice, a manageable one. FireBreak™ is designed to be operated by the same staff who already control critical systems — network, security, and processing teams. Standard operating procedures define when and how ports are opened or closed. Accidental disconnection carries a similar risk profile to accidentally removing a patch cable, which trained operations staff already manage routinely.

‍

Two primary operational models exist:

1. Normally connected — the FireBreak™ sits inline and is triggered to disconnect in response to a threat, alert, schedule, or procedural event
2. Normally disconnected — assets are isolated by default and only connected when service is actively required, such as during scheduled maintenance windows or authorized third-party access

Many deployments use a combination of both models across different segments.

‍

No. By design. Disconnection and reconnection require explicit authorized commands. This prevents accidental reconnection but also means operational procedures must be defined for returning to a connected state after an isolation event.

Yes. Time-based port scheduling is a supported operational mode and is useful for DevOps segregation, timed third-party access windows, or out-of-hours isolation of non-critical systems.

No. FireBreak™ operates at a layer beneath and independent of your existing stack. Think of it as the physical enforcement layer that makes all other controls more effective and provides a backstop when they fail. Your detection tools still detect; FireBreak™ is what you use when detection alone is not enough.

‍

Ransomware spreads laterally over network connections. FireBreak™ allows an operator — or an automated trigger from a SIEM or SOAR platform — to physically sever the network path in seconds, stopping lateral movement before it reaches backups, adjacent segments, or critical systems. It also physically isolates backup infrastructure so ransomware cannot encrypt or exfiltrate backup data during an attack.

Yes. The API trigger interface supports automated, policy-driven disconnection. This allows FireBreak™ to act as a hardware-enforced response action within an existing orchestration workflow — enabling machine-speed isolation without requiring human intervention.

Minimal by design. The protected data path has no IP presence, no firmware exposure, and no software logic — it is a physical relay. The control plane is out-of-band, access-controlled, and separately managed. There is no pathway from the protected network to the control interface.

FireBreak™ directly supports the physical segmentation, resilience, and rapid incident response requirements common to NIS2, DORA, IEC 62443 (OT security), and sector-specific mandates in finance, healthcare, and critical infrastructure. It provides an auditable, hardware-enforced control that regulators can inspect independently of software policy configurations.

‍

Yes — and this is one of its strongest use cases. Legacy OT and SCADA systems are frequently unpatched and cannot run endpoint security software. FireBreak™ protects them at the physical layer without requiring any modification to the protected device. It enforces the IT/OT boundary required by regulations such as IEC 62443 and NERC CIP, which are often difficult to implement purely in software.

Financial institutions face dual regulatory pressure (DORA, PRA, and FCA) alongside a high-value attack profile. FireBreak™ enables physical enforcement of dual-authorization access controls, instant isolation of trading or processing systems under attack, physical separation of backup environments, and time-locked third-party access — all independently auditable.

‍

Healthcare environments combine legacy medical devices, IT systems, and operational infrastructure, with patient safety directly tied to uptime. FireBreak™ provides the ability to isolate compromised segments instantly without taking down the entire network, protecting clinical systems while containing a breach. The same principle applies across water utilities, energy, and aviation CNI environments, where partial disconnection — not full shutdown — is the operational imperative.

Yes. Converged BMS environments — where HVAC, access control, and power management share infrastructure with IT networks — are increasingly targeted as entry vectors into financial or operational systems. FireBreak™ physically enforces the boundary between BMS and enterprise IT, removing the lateral path attackers use to pivot from a compromised building system into core infrastructure.

Law firms and professional services firms handle highly sensitive client data under privilege obligations. FireBreak™ enables per-client or per-matter physical vaulting of data — segments that are literally unreachable except during scheduled, authorized access windows. This is a materially stronger confidentiality control than access management software alone.

Yes. It integrates into any standard network infrastructure and requires no forklift upgrade, no changes to existing devices, and no new software agents on protected systems. It is compatible with any vendor’s switches, routers, or firewalls.

FireBreak™ appliances are deployed at key network segmentation points — between IT and OT, at the perimeter of backup environments, at third-party access ingress points, or protecting specific high-value asset clusters. A typical enterprise deployment involves identifying critical choke points, deploying appliances at each, and defining operating procedures for both normal and incident states. Goldilock’s team supports this through the solution blueprint program.

Yes. Goldilock launched a global distributor and reseller program in 2025 to enable partners to bring FireBreak™ to market across all sectors. Partners gain access to sales enablement, technical certification, and solution blueprint resources.

Contact the team at sales@goldilock.com or schedule directly via the website. Goldilock supports both remote demos and on-site proof-of-concept deployments.