Your firewall change control works. Every rule edit goes through a request, gets approved, and lands in an audit trail. But that discipline stops at the firewall. The same security-relevant changes happen every day on switches, routers, and cloud security groups, and most of them never go through a request at all. An engineer widens a security group to 0.0.0.0/0 to debug something, forgets to revert it, and there is no record it ever happened. The firewall stays pristine while the gap opens behind it.
This post is about why change management cannot stop at the firewall, and where we are taking CyberX to close that gap across network infrastructure and cloud workloads.
Key takeaway: Firewalls are one control plane among many. The same unauthorized-change problem CyberX solves for firewall rules exists on every switch, router, and cloud security group in your environment. We are extending CyberX’s detection, approval workflows, and audit trails to those endpoints so that “who changed what, when, and was it approved” has a single answer across your whole estate.
What is endpoint change management?
Endpoint change management is the practice of detecting, approving, and recording configuration changes across all enforcement and infrastructure endpoints, not just firewalls. That includes the running config on switches and routers, and the policy objects that govern cloud workloads such as security groups, network ACLs, and IAM rules. The goal is the same as firewall change management: no change reaches production state without an approved request behind it, and every change is attributable.
Why does drift on network gear and cloud go unnoticed?
Most teams watch firewall changes closely because the firewall is a single, high-value chokepoint. Network devices and cloud policies are a different story. They are numerous, owned by different teams, and changed through a dozen paths: vendor CLIs, config management tools, cloud consoles, and API calls. A change made directly on a device or in a console often leaves no trace outside that system’s own logs, which nobody reviews until something breaks.
That gap between the state you approved and the state actually running is configuration drift, and drift is where breaches live. The 2017 Equifax breach traced back to an unpatched Apache Struts instance (CVE-2017-5638). Capital One’s 2019 breach involved a misconfigured web application firewall and an over-permissioned IAM role, as detailed in the company’s incident disclosure. Neither was a zero-day on the firewall. Both were configuration that drifted from intent and stayed that way.
Through 2023, 99% of cloud security failures will be the customer’s fault, and the leading cause will be misconfiguration. (Gartner)
The same controls, applied to more surfaces
CyberX’s firewall change management rests on three pillars: detect unauthorized changes, route every change through approval, and record an immutable audit trail. None of those are firewall-specific. They apply to any system with a configuration state worth protecting. Here is how each maps to the endpoints we are expanding to.
| Capability | On firewalls (today) | On network gear and cloud (where we are headed) |
|---|---|---|
| Unauthorized change detection | Rule and object diffs against approved baseline | Device running-config diffs, cloud policy and security-group diffs |
| Change request workflow | Rule edits require an approved request | Device config pushes and IAM or security-group edits require the same approval gate |
| Audit trail | Immutable record of who changed which rule, when | Unified record spanning firewall, device, and cloud changes in one timeline |
| Multi-tenant MSP access | Per-client firewall isolation | Per-client isolation extended across the client’s full endpoint estate |
This is not bolting on unrelated features. The model you already trust for firewalls is the right model for the rest of the estate, and you should not need five different tools and five different audit exports to prove it.
Which endpoints are in scope?
We are starting with the endpoints that share the firewall’s most important property: a bounded, well-defined configuration you can baseline and diff. That is network infrastructure and cloud policy. Servers are a harder problem (there is no single “the config” to diff, and Windows registry state alone is enormous), so we are deliberately not tackling them in this phase.
Network infrastructure
Switches, routers, and load balancers carry running configurations that are every bit as security-relevant as a firewall rule set, and just as diffable. A VLAN reassignment, an ACL edit, a new trunk port, or an SNMP community string left at default can each open a path that the firewall was never positioned to see. These devices are also where “temporary” changes go to die, because the person who made the change is often the only person who knows it exists.
# The kind of change that should never land without an approved request
# switch running-config
- access-list 101 deny ip any 10.0.0.0 0.255.255.255
+ access-list 101 permit ip any anyDetecting that diff against an approved baseline, and being able to point at the request that authorized it (or flag that there was none), is the entire game.
Cloud workloads
In cloud environments the “firewall” is a set of security groups, network ACLs, and IAM policies that any engineer with console access can change in seconds. These are the configurations behind a large share of public cloud incidents. Treating a security-group change or an IAM policy edit with the same request-and-approve discipline as a firewall rule change is not optional once your workloads are in scope for the same audits.
What this means for compliance
Auditors have never scoped their questions to the firewall. The change-management requirements in the major frameworks cover every system in scope, network devices and cloud resources included. Extending CyberX to those endpoints means one set of evidence answers the requirement everywhere, instead of a firewall export plus a pile of manual screenshots for everything else.
| Framework | Relevant requirement | Why endpoint scope matters |
|---|---|---|
| PCI DSS 4.0 | Requirement 1 (network security controls) and 6.5.1 (change management) | Applies to all system components in the cardholder data environment, not just perimeter firewalls |
| SOC 2 | Common Criteria CC8.1 (change management) | Covers changes to infrastructure, data, software, and procedures across the system boundary |
| ISO 27001 | Annex A 8.32 (change management) | Requires controlled changes to information processing facilities and systems generally |
| NIST SP 800-53 | CM-3 (configuration change control), CM-6 (configuration settings) | Configuration management controls apply to the full information system, network devices and cloud included |
If you have ever assembled a SOC 2 change-management evidence package, you know the firewall part is easy and everything else is a scramble. Unifying that record is one of the main reasons we are building this.
How to get your environment ready
You do not need to wait for endpoint support to ship. The teams that adopt fastest will be the ones who have already done the groundwork.
- Inventory the endpoints that actually carry security-relevant configuration: network devices and cloud accounts. You cannot manage change on assets you have not enumerated.
- Define the approved baseline for each class. For devices, that is the approved running config. For cloud, the intended security-group and IAM posture.
- Identify every path a change can take into those systems, and decide which ones should route through an approval gate.
- Map your compliance obligations to specific endpoint types now, so the evidence requirement is clear before the audit, not during it.
- For MSPs: confirm your per-client isolation model extends cleanly to non-firewall assets, so endpoint change data stays tenant-scoped from day one.
Bottom line: The firewall was never the whole perimeter, and unauthorized change is not a firewall-specific problem. The detection, approval, and audit discipline you trust for firewall rules belongs on every switch, router, and cloud policy that can change your security posture. That is the direction we are taking CyberX.
CyberX already gives you a single source of truth for firewall change: detection, approval workflows, and immutable audit trails, with multi-tenant isolation for MSPs. Extending that same control plane to network infrastructure and cloud workloads is on our roadmap, so “who changed what, when, and was it approved” has one answer for your entire environment. If endpoint change management is a gap you are already feeling, we would like to hear how your estate is structured.