A SCADA vendor has declined to enable a basic safeguard across its platform because it expects some customers to object to the change. That decision alone does not establish whether the safeguard is required, whether the reported flaw is exploitable, or whether a state audit applies. Separate those questions before deciding how to escalate the issue.
What exactly does the reported security issue do?
Translate the concern into a testable security claim. “A basic feature is missing” describes a design choice; it does not yet describe an exploitable vulnerability. Record the affected product and configuration, the security boundary involved, the attacker access needed, the action possible, and the resulting impact on confidentiality, integrity, or availability. Do not publish customer-identifying details while establishing the claim.
| Question to document | Evidence to collect | Why it matters |
|---|---|---|
| What is exposed? | Product component, interface, service, or configuration involved | Identifies where the claimed weakness resides. |
| What access does an attacker need? | Network position, account privilege, or other prerequisite | Distinguishes a remotely reachable path from an issue requiring prior access. |
| What can the attacker do? | Repeatable steps and observable result in an authorized test environment | Connects the behavior to operational risk rather than a feature preference. |
| Which installations are affected? | Product versions, configuration conditions, and deployment boundaries | Defines who needs remediation and what evidence to request from the vendor. |
Reproduce only in an authorized environment, preserve logs and configuration details, and separate observed behavior from assumptions about impact. If the vendor disputes that the behavior is a vulnerability, ask it to identify the disputed prerequisite, exploit path, or impact; then resolve that point with a repeatable test. Check before proceeding: another qualified reviewer can follow the documented steps and observe the same result without relying on verbal descriptions.
Who owns the system and the risk decision?
A SCADA product provider and the organization operating the controlled assets have different roles. A vendor develops and maintains a product; the asset owner selects, configures, connects, and operates it within a particular environment. A product weakness can affect owner risk, but that does not make the provider the operator of every customer’s system or transfer the owner’s system-level decisions to the provider.
For the municipality in this case, identify the asset owner, the system owner, the procurement authority, the cybersecurity lead, and the operational authority that can approve changes. Establish whether the affected deployment is owned or operated by the municipality, a service provider, or another entity. The party that can authorize testing, accept residual risk, or schedule a production change may differ for each task.
| Decision | Primary place to resolve it | Record |
|---|---|---|
| Does the behavior exist? | Authorized product test with vendor technical review | Reproduction procedure and results |
| Can the deployed system be exposed? | System owner and controls/network team | Deployment inventory and data-flow or access review |
| Can a safeguard be enabled safely? | Product owner, vendor, and operational change authority | Compatibility, operational impact, and rollback plan |
| Who accepts remaining risk? | Organization’s authorized risk owner | Decision, rationale, mitigations, and review date |
Check before proceeding: name the role authorized to test, the role authorized to change production, and the role authorized to accept any remaining risk. Do not treat an informal vendor conversation as any of those approvals.
Does a state audit requirement apply to this provider?
Do not infer a state audit duty from the fact that a SCADA provider serves customers in multiple states. The question is not answered by the product category alone. Requirements can depend on the asset owner, the service being provided, the relevant jurisdiction, contract language, and the particular asset or operation. The discussion here indicates that SCADA providers are not typically subject to direct state audits, while some controlled assets can carry risk-management requirements; that is a general distinction, not a determination for a specific provider or municipality.
Build the applicability decision from authoritative records rather than assumptions:
- Identify the legal entity that owns or operates the affected asset and where that asset is located.
- Ask the organization’s counsel, compliance lead, or regulator-facing authority which laws, regulations, directives, or contractual commitments apply to that entity and operation.
- Check whether the vendor contract, procurement terms, security addenda, or service agreement requires assessments, audit rights, testing, incident notification, or remediation practices.
- Determine whether those obligations flow down to the provider and whether the contract specifies evidence or remedies for nonperformance.
Do not substitute a vendor’s marketing claim, a customer’s audit report, or a third-party penetration test for a legal applicability review. Those documents may inform assurance, but they do not by themselves establish that a state audit is mandatory or that a particular control is legally required. Check before proceeding: have the responsible compliance or legal authority identify the applicable obligation and its scope in writing.
What evidence should a vendor security review request?
If the audit question resolves to customer procurement or assurance rather than a direct state inspection of the provider, evaluate the provider through documented security practices. Request information proportionate to the system’s operational consequence and the provider’s role. The discussion identifies third-party penetration testing and vulnerability-management processes as relevant considerations; neither is a substitute for understanding the deployment or the reported issue.
| Review area | Request or verify | What the result tells you |
|---|---|---|
| Vulnerability handling | How reports are received, triaged, assigned, remediated, and communicated | Whether there is a repeatable process beyond one conversation. |
| Product testing | Scope and recency of independent security testing, plus treatment of findings | What was assessed and whether issues were tracked to disposition. |
| Product configuration | Which security controls are available, their defaults, and any operational dependencies | Whether customers can apply protections and what changes they must plan. |
| Customer obligations | Published hardening, upgrade, and deployment guidance | Which protections depend on customer configuration or maintenance. |
| Contractual assurance | Audit rights, evidence delivery, notification, and remediation terms | What the customer can require and enforce under the agreement. |
Ask for evidence linked to the affected product and the specific concern, not just a broad assurance statement. A penetration test with a different scope may not cover the disputed safeguard. Check before proceeding: the review record names the evidence received, its scope, gaps, owner, and next action.
How should the safeguard decision be evaluated?
A vendor’s concern about customer inconvenience is an operational tradeoff, not a technical explanation of whether the safeguard reduces risk. Determine what the control changes, whether it is configurable, what legitimate workflows it affects, and whether a safer alternative exists. Because the claimed control was not described, do not assume that enabling it is universally safe or that a single global default is appropriate.
Ask the vendor to provide a written product-level analysis: threat addressed, affected versions or configurations, expected user impact, alternatives, and recommended deployment conditions. Ask the asset owner’s operations team to test the change in a representative nonproduction environment. Include normal operating workflows, recovery procedures, remote access paths, and any integration behavior the control could affect. If the control can be enabled per deployment, assess that path against an all-customer default change; if it cannot, ask how the vendor controls exceptions and communicates risk.
Where the safeguard cannot be enabled immediately, document compensating measures selected for the actual deployment, such as reducing exposure through network access restrictions or limiting privileges where applicable. These are risk-reduction options, not proof that the vulnerability is fixed. Record who accepted the residual risk, what evidence supports that decision, and when the decision will be reviewed.
Check before proceeding: obtain an approved change or risk decision that states the tested configuration, operational impact, rollback path, any temporary mitigation, and responsible owner.
How can the issue be escalated without disclosing customer details?
Use a coordinated reporting path. Send the vendor a concise technical report through its designated security-reporting mechanism, if one exists. Include reproduction conditions, impact, affected product/configuration information, and supporting evidence. Avoid sending production credentials, customer data, or unnecessary network details. Request confirmation that the report was received, a technical assessment, and a communication plan for affected customers.
If the vendor does not engage or the potential impact warrants outside coordination, the source identifies MS-ISAC or CISA as possible contacts. Use an official channel suitable for the organization and follow its instructions for disclosure and evidence handling. Do not disclose exploit details publicly while coordination and impact assessment remain active. Preserve a dated record of reports, acknowledgments, responses, and decisions.
Check before proceeding: the report recipient has acknowledged the issue, the organization has a named contact responsible for coordination, and the evidence is stored in an approved location with access limited to people who need it.
What proves the final SCADA risk decision is complete?
Close the loop from product behavior to the deployed system. A vendor statement that a feature exists, a successful laboratory test, or an audit report alone does not prove that the municipality’s installation is protected. Verify the selected action at the boundary where the risk occurs and retain the result.
- Confirm the exact affected product and configuration in the deployed system against the vendor’s applicability statement.
- Test the safeguard or approved mitigation in the representative environment; verify that the risky behavior is blocked and required operator workflows still function.
- Confirm the production change through configuration records and a post-change test authorized by the system owner.
- Review monitoring and logs for the expected security behavior, and assign an owner and review date for any remaining risk or vendor remediation.
- Store the test result, vendor communication, applicability determination, approval, and residual-risk decision together so an auditor or future maintainer can trace the conclusion.
Final verification: the system owner confirms that the deployed configuration matches the tested configuration, the safeguard or mitigation works in the production context, and any unresolved risk has an authorized owner and scheduled review.
SCADA vendor audit and security questions
Are SCADA vendors subject to state security audits?
There is no universal answer based on the provider serving customers in several states. Check the provider’s applicable legal obligations and contracts with the responsible compliance or legal authority; some requirements may attach to the asset owner or operation instead.
How do I prove a SCADA product has a vulnerability?
Document the affected component and configuration, required attacker access, repeatable test steps, observed result, and operational impact. Reproduce only in an authorized environment and ask the vendor to address any disputed prerequisite or impact.
How do I report a SCADA security issue if the vendor does not respond?
Keep the technical report and correspondence, use the vendor’s designated security-reporting path when available, and request acknowledgment and a coordinated communication plan. The organization can also contact MS-ISAC or CISA for coordination guidance, while limiting disclosure of exploit and customer details.
How do I verify a SCADA safeguard fixed the risk?
Test the safeguard in a representative environment, verify the risky behavior is blocked without breaking required workflows, then confirm the deployed configuration matches the tested one. Record the result and assign an authorized owner and review date for remaining risk.