Firewall, WAF, EDR, NDR, identity, vulnerability management, PKI
Executive reference architecture
See where Breakwater runs, what crosses a boundary, and who can act.
Breakwater ASOC connects supported, customer-approved security controls to attributable evidence, validation, explicit authority, and post-change verification. The reference model makes those boundaries visible before an evaluation begins.
Evidence-to-action
One decision chain, with customer authority drawn around it.
This executive view shows logical control and decision authority, not physical hosting. Module placement may be customer-hosted, Breakwater-hosted, or hybrid as agreed for the deployment. It is not a claim that every connector or action is available in every installation.
Existing controls feed Breakwater Secure and the shared evidence layer. Breakwater Assure validates findings. A named customer authority gate controls Breakwater SOAR response and verification.
EXISTING CONTROLS
ScannersEDR / NDRSIEMCMDBAppSecIdentity
Signals enter with source, time, scope, and coverage context.
CUSTOMER-CONTROLLED DECISION BOUNDARY
OBSERVESecure
Assets · services · protocols · cryptography · paths
SHARED EVIDENCEAttributable records
Identity · provenance · confidence · ownership · history
VALIDATEAssure
Source trace · replay · coverage · human review
ACTION BOUNDARY
GOVERN + VERIFYSOAR
Case · bounded action · result · verification
The customer controls the deployment boundary, approved data paths, credentials, action permissions, and human authority. Breakwater capabilities operate only within the integrations and scope made available to them.
Component-level architecture
Local truth stays local. Decisions move through an attributable control plane.
This reference topology shows the responsibilities and trust boundaries to resolve during deployment. Exact components, connectors, and execution permissions are confirmed for each customer environment.
Customer infrastructure and existing controls connect to local Breakwater sensors, connectors, and an evidence vault. Approved evidence moves to the ASOC control plane where Secure observes, Assure validates, and SOAR governs approved response through a customer-controlled action relay.
01 / CUSTOMER ESTATEControls and owners remain authoritative
Passive taps, gateways, PLCs, HMIs, cameras, building and safety systems
IAM, posture, flow logs, CI/CD, SAST, SBOM, SaaS audit sources
Observed telemetry + imported context↓
02 / CUSTOMER-CONTROLLED EVIDENCE LAYERCollection beside the systems that produce the truth
Passive or authorized active observation, normalized with identity, time, and scope
Least-privilege API polling and webhooks from approved native controls
Raw packet data, payloads, and sensitive artifacts stay local unless a named owner approves retrieval
Authenticated, tenant-scoped evidence + claims↓
03 / ASOC CONTROL PLANE · AGREED PLACEMENTCustomer-hosted, Breakwater-hosted, or approved hybrid
Asset identity, relationships, exposure, attack paths, cryptographic posture
Source replay, provenance, coverage, claim state, and human review
Case, policy, named approval, bounded action, rollback, and verification
API gateway + ingestionAsset + relationship graphApproved evidence + audit storeHealth + operations
Signed action scope + expiry + rollback↓
04 / CUSTOMER ACTION BOUNDARYNothing consequential executes by implication
Customer IdP, role, policy, approver, time box, and blast-radius limits
Allowlisted, least-privilege actions only where an integration and customer approval exist
New evidence checks whether the intended condition changed and records the result
CISO questions
Architecture answers the questions a product diagram usually hides.
Before a pilot, buyers need more than a list of features. They need to know where sensitive evidence lives, how claims are supported, and how automation is constrained.
Where does the evidence live?
Collection and evidence-storage placement is defined during evaluation. Where customer-controlled placement is required and supported by the selected modules, the accepted topology is documented before deployment.
What is allowed to leave?
Only deployment-approved data paths may cross the customer boundary. Where local processing or restricted connectivity is required, that becomes an explicit design constraint.
What can automation change?
Nothing consequential by implication. Actions require an available integration, defined scope, appropriate credentials, policy, and the customer’s chosen approval model.
How is success established?
Where post-change assessment is enabled, Breakwater collects fresh evidence and records whether the intended condition changed, not merely whether a playbook ran.
Responsibilities
The modules connect, but their jobs stay distinct.
Clear responsibility reduces duplicate claims and makes it easier to start with the module that addresses the buyer’s immediate decision.
Establish the operating picture.
Connect infrastructure, application-adjacent, and cryptographic observations to asset identity, scope, and plausible exposure.
Does not turn every observation into a confirmed risk.Challenge the security claim.
Preserve source and coverage, reproduce evidence where supported, and keep human review explicit.
Does not treat scanner or model output as authority.Control and close the response.
Bind the case to ownership, authorization, bounded action, rollback, and verification.
Does not bypass the customer’s authority model.Physical operating reality
The cyber question changes when downtime reaches the physical world.
Breakwater connects technical exposure to the systems, owners, and consequences that determine whether an action is safe.
AIRPORTS + TRANSPORTATION
Protect movement without interrupting it.
Relate cameras, access control, baggage, building systems, vendor links, and network paths to operational zones and service ownership.
Decision: Which path creates material exposure, and what can change without disrupting passenger or safety operations?See how Secure, Assure, and SOAR fit here →
POWER + UTILITIES
Prioritize resilience, not finding volume.
Connect substations, remote sites, engineering access, legacy protocols, and compensating controls to the paths that could affect continuity.
Decision: Which exposure can affect service, and which response fits the safety and change-control boundary?See how Secure, Assure, and SOAR fit here →
CONNECTED INDUSTRY
See cyber risk in production context.
Map PLCs, HMIs, gateways, unsupported devices, maintenance routes, and enterprise dependencies without assuming every reachable system can be patched.
Decision: Where is the attack path, who owns the process, and which containment or compensating control is operationally viable?See how Secure, Assure, and SOAR fit here →Deployment patterns
Fit the operating boundary before expanding the feature surface.
These are patterns to evaluate, not universal availability commitments. A deployment design is accepted only after integrations, data paths, and operational ownership are confirmed.
On-site or private environment
Place collection and evidence services inside infrastructure controlled by the customer, with access and egress governed by customer policy.
Disconnected or tightly constrained
Evaluate local processing, offline transfer, update, and evidence-handling requirements where persistent external connectivity is not permitted.
Controlled service integration
Use authenticated, tenant-scoped connections only where the customer approves the data class, destination, purpose, and retention boundary.
Category-level positioning
Breakwater sits between security signals and accountable decisions.
Most tools are optimized for one control surface. Breakwater connects their output to evidence quality, operating context, authority, and verification.
Category-level positioning only. This is not a vendor benchmark or performance claim.
| Market category | Typical center of gravity | Breakwater position | Decision supported |
|---|---|---|---|
| OT / IoT asset visibility | Discover devices and monitor network behavior | Connect identity, relationships, protocols, firmware, reachability, operational zone, and evidence coverage. | What changed, what is exposed, and where is confidence incomplete? |
| Attack surface + vulnerability management | Find assets and prioritize known vulnerabilities | Keep provider coverage, candidate attack paths, business ownership, and remediation rehearsal tied to evidence and scope. | Which plausible path deserves validation and action first? |
| SAST / SCA / AppSec | Find source and dependency issues | Emphasize source-verifiable claims, replay, refutation, coverage limits, and human decision states. | Can engineering defend this finding and its remediation? |
| SIEM / SOAR | Correlate alerts and automate playbooks | Center evidence class, authorization, blast radius, rollback, and fresh verification before and after action. | What may change, who approves it, and did the change work? |
| GRC + compliance evidence | Collect control evidence and workflow approvals | Derive decision records from observed claims, source snapshots, ownership, exceptions, and history. | What proof supports the posture statement and its limits? |
| PQC inventory + migration | Catalog cryptographic capability and exposure | Relate advertised capability to observed negotiations, certificates, communication paths, ownership, and migration priority. | Which relationships remain classically exposed and who owns the transition? |
Plan the boundary
Bring us the decision, the environment, and the constraints.
We will define a bounded evaluation with explicit evidence sources, success criteria, permissions, and operating ownership.