Mendix SAML CVE-2026-80465: 8.8, 8.7 and 6.8 Explained

On 26 October 2026 Siemens ProductCERT did two separate things to the same software component in a single day. It published a new advisory for a replay flaw in the Mendix SAML module, and it revised an older advisory for a signature-validation flaw in that same module, changing the recommended fixed versions because, in Siemens' own words, "the previous versions did not fully remediate the vulnerability." Three days later CISA republished the first of those two as ICSA-26-302-01.

The consequence is that the severity attached to "the Mendix SAML vulnerability" depends entirely on which page you happen to open: 8.8, 8.7, 7.6, 6.8, or 9.1. Five numbers, four of which are real, and one of which belongs to an advisory that has been formally withdrawn. If your risk register, your ticket queue, or your AI-assisted summary picked up any single one of them, it is probably incomplete.

This article separates the threads. It covers CVE-2026-80465, the account hijacking flaw in SSA-887643; CVE-2026-89209, the replay flaw in SSA-137528; the revoked CVE-2026-7891; the version ladder you actually have to reach; and why a low-code platform identity bug ends up as a plant maintenance item rather than a purely corporate IT one. Everything factual below comes from the vendor advisories, the vendor's own advisory index, NVD records and the CISA page, all fetched on 30 October 2026. Where we extend past those documents, we label it as our own reasoning.

Key takeaways

• There are two current Siemens advisories on the Mendix SAML module, not one. SSA-887643 covers CVE-2026-80465 (improper verification of the SAML response signature, CWE-347). SSA-137528 covers CVE-2026-89209 (insufficient protection against SAML assertion replay in IdP-initiated flows, CWE-294).
• 8.8 and 8.7 are the same vulnerability. Siemens publishes both a CVSS v4.0 base score of 8.8 and a CVSS v3.1 base score of 8.7 for CVE-2026-80465. They are different scales, not a correction.
• 6.8 is also correct, but for the other CVE. CVE-2026-89209 scores 6.8 on v3.1 and 7.6 on v4.0.
• The fix version is 4.2.4, not 4.2.3. Both advisories describe every build below V4.2.4 as affected on the Mendix 10 and Mendix 11 compatible modules, and every build below V3.6.29 on the Mendix 9 compatible module. A migration plan that stops at 4.2.3 has not remediated either flaw.
• SSA-887643 is a revision, and the revision matters. Version V1.1, dated 26 October 2026, states that new fixed versions were released because the previous ones did not fully remediate the vulnerability.
• CISA mirrored only one of the two. ICSA-26-302-01 is a verbatim republication of SSA-137528 and carries a single vulnerability at CVSS v3 6.8. The 8.8 advisory has no CISA page in this release, which is the most likely reason the two numbers got mixed up in circulation.
• Neither flaw is listed as exploited. The CISA Known Exploited Vulnerabilities catalog released on 29 October 2026 holds 1,764 entries and contains no Mendix listing of any kind.

What is CVE-2026-80465?

Siemens Security Advisory SSA-887643 is titled "Account Hijacking Vulnerability in Mendix SAML module". Its first version was published on 3 September 2026; the page we fetched on 30 October shows a publication date of 3 September 2026, a last update of 26 October 2026, and current version V1.1.

The technical description is short and specific: "Affected versions of the module do not properly validate the SAML response signature. This could allow unauthenticated remote attackers to hijack an account (session) in specific SSO configurations." The weakness is classified as CWE-347, Improper Verification of Cryptographic Signature.

That is a different failure from the one in the newer advisory. Signature validation is the step where the service provider checks that the SAML response really was signed by the identity provider your application trusts. If that check can be bypassed, an attacker does not need to intercept or replay anything that already happened; they need to present a response the module wrongly accepts. Replay, by contrast, is the reuse of a response that was valid and genuinely signed. Both end at the same place, an authenticated session belonging to somebody else, but they start from different defects and they are not mitigated the same way.

One detail worth flagging because it is frequently transplanted between the two advisories: the "disable IdP-initiated SSO" mitigation appears in SSA-137528, not in SSA-887643. The account hijacking advisory has no vendor-authored mitigation section at all; its mitigation chapter points only at the product-specific remediation table and at Siemens' general security recommendations. Turning off identity-provider-initiated login is a reasonable defensive step for a replay flaw. Nobody at Siemens has claimed it substitutes for patching a signature-validation flaw, and it should not be recorded as if they had.

For context on what the component is, Siemens' own product description in SSA-137528 says the Mendix SAML module "allows you to use SAML to authenticate your users in your cloud application" and "can communicate with any identity provider that supports SAML2.0 or Shibboleth". It is a marketplace component, not part of the Mendix Runtime itself, which is why the remediation is expressed in module versions rather than platform versions.

Two advisories, one module: the difference at a glance

Read the last two rows together. The advisory with the higher score is the one CISA did not republish on 29 October, and the advisory CISA did republish is the one whose mitigation text is now circulating on its own. That combination is exactly how a single "Mendix SAML vulnerability" story ends up with contradictory numbers in different feeds.

Why the same flaw carries three scores

Take CVE-2026-80465 alone. Siemens publishes two base scores for it, one per CVSS version, and they are not convertible into each other.

The full vectors, as published: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N and CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N.

Two things follow. First, the high score is not driven by ease of exploitation. Attack complexity is High in both scales, and v4.0 explicitly records attack requirements as Present, meaning the vulnerable configuration has to be in place. What pushes the score up is the combination of no privileges required, high confidentiality and integrity impact, and a scope change: a defect in one module compromises the application that depends on it.

Second, the "specific SSO configurations" phrase in the description is load-bearing, and it is the same phrase Siemens used for CVE-2025-40758 a year earlier. It means the vendor is not asserting that every Mendix application using SAML is exposed. It means the exposure depends on how the module is configured and deployed. You cannot answer the question from the CVE record; you have to answer it from your own application inventory.

The third and fourth numbers, 6.8 and 7.6, belong to CVE-2026-89209 with vectors CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N and CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. The v3.1 difference from the other CVE is instructive: user interaction is Required and scope is Unchanged, so the same impact on the same component scores 1.9 points lower. Whether you think that gap is proportionate is a judgement call; what matters operationally is that both advisories converge on the same remediation version, so the choice between them is not a triage decision you have to make.

Which versions fix it, and why 4.2.3 is not one of them

Anything below V4.2.4 on the current-generation lines is affected, which includes V4.2.3. If a summary told you to move to "4.2.3 or later", that instruction is now wrong in the direction that matters, and it is wrong because of a document change rather than a typo. SSA-887643 V1.0 was published on 3 September 2026. Its history entry for V1.1, dated 26 October 2026, reads: "Released new fixed versions, as the previous versions did not fully remediate the vulnerability."

We could not retrieve the superseded version numbers from V1.0 of that advisory, so we will not guess them here; the archived copy was unavailable when we checked. What we can say is that the current published range is unambiguous, that both advisories agree on it, and that a single module upgrade to V4.2.4 or V3.6.29 is the remediation for both flaws at once.

One naming inconsistency to watch: the account hijacking advisory scopes the legacy line as "Mendix 9.24 compatible", while the replay advisory and the CISA page say "Mendix 9 compatible". Treat every 3.6.x build below V3.6.29 as exposed regardless of which Mendix 9 minor you run, and do not rely on a 9.x version string to tell you whether the module is patched. The module version is the fact that matters; the platform version only tells you which module branch you should be on.

What CISA published, and what it did not

ICSA-26-302-01, "Siemens Mendix SAML Module", carries a release date of 29 October 2026. Its revision history shows an initial release date of 26 October 2026 for revision 1 and, for revision 2 on 29 October, "Initial CISA Republication of Siemens ProductCERT SSA-137528 advisory". It lists one vulnerability, CVE-2026-89209, one affected weakness, CWE-294, and a CVSS v3 base score of 6.8. CISA tags the affected sectors as Critical Manufacturing and Information Technology, deployment worldwide, vendor headquarters in Germany, and credits Siemens ProductCERT with reporting the vulnerability.

The remediation block on each affected product line repeats both options: the mitigation "Disable IdP-initiated SSO" and the vendor fix "Update to V4.2.4 or later version", with V3.6.29 on the Mendix 9 line.

Two caveats belong in any register built from that page. The first is scope: because ICSA-26-302-01 mirrors only SSA-137528, a reader who works exclusively from CISA will not see CVE-2026-80465 at all in this release. The second is provenance. The advisory carries CISA's standard conversion disclaimer, stating that the ICSA is a verbatim republication of a vendor CSAF advisory, provided as-is for informational purposes, with CISA not responsible for editorial or technical accuracy and not endorsing any product. That is a fair description of how these pages behave: authority comes from the vendor document behind them, so the version of the vendor document you cite has to be the current one.

On exploitation status, we checked the Known Exploited Vulnerabilities catalog directly. The edition released on 29 October 2026 at 19:09 UTC contains 1,764 entries. Neither CVE-2026-80465 nor CVE-2026-89209 appears in it, and no Mendix product appears anywhere in it. Neither advisory reports active exploitation either. Absence from the catalog is a statement about what has been confirmed, not about what has been attempted.

The 9.1 that no longer exists

If your feed shows a 9.1 for Mendix, that entry is void, and it is worth knowing how it was retired because the same thing can happen to the advisories above.

ICSA-26-209-02 concerned Siemens Mendix Runtime and CVE-2026-7891, described as "Insecure Inherited Permissions" with a CVSS v3 score of 9.1. CISA's revision history runs: initial publication 14 July 2026; republication of Siemens ProductCERT SSA-814963 on 28 July 2026; "Revoked advisory as the CVE is rejected" on 22 September 2026; and an Update A on 24 September 2026, "Revoking advisory after Siemens revoked SSA-814963 and rejecting CVE-2026-7891". The NVD record for that CVE now carries the status Rejected, with the reason: "This CVE has been retracted. Re-investigation confirmed the reported behavior is expected platform configuration and does not expose the protected attribute."

A 9.1 on a runtime used for industrial applications is exactly the kind of entry that gets copied into a control-system risk register and then never revisited. It also gets absorbed into web-scale summaries and, three months later, still surfaces in generated answers. The practical lesson is narrower and more useful than "do not trust the internet": record the advisory identifier and the advisory version, not just the CVE and the score, because the version is the only field that tells you whether the document you read is still current.

A five-year pattern in one module

Mendix maintains its own security advisory index, and the SAML module appears in it repeatedly. This is the recurrence list as that index presents it, cross-checked against NVD for the older entries.

Eleven entries in six years for one marketplace module. Group them by failure mode and the pattern is clear: the trust boundary between an identity provider and an application has been re-broken in this component repeatedly, in three distinct ways. Privilege escalation dominates 2021 and 2022. Authentication bypass and replay cluster in 2022, 2023 and again in 2026. Signature and binding validation is the 2025 and 2026 theme, and the 2025 entry, CVE-2025-40758, uses almost the same language as this year's: "insufficiently enforce signature validation and binding checks ... could allow unauthenticated remote attackers to hijack an account in specific SSO configurations". Same score, 8.7, one year apart.

Two of the 2022 entries are also directly relevant to this year's replay flaw. CVE-2022-37011 and CVE-2022-44457 are both titled "Authentication Bypass Vulnerability in Mendix SAML", and the 2022 NVD record for CVE-2022-37011 describes insufficient protection against packet capture replay, gated on a non-default configuration option for allowing identity-provider-initiated authentication. That is the same configuration surface CVE-2026-89209 is now asking you to turn off. We are treating the connection as an observation from the published records, not as a vendor statement.

The conclusion we would draw is procedural rather than alarmist. A module with this record is not a set-and-forget dependency. It needs an owner, a version baseline, and a subscription to the vendor advisory feed, in the same way that a controller firmware line does. When we say the fix is cheap here, we mean cheap in engineering effort, not free in governance.

How to tell whether your Mendix application is exposed

Neither advisory tells you whether you are affected, because that depends on your configuration. This checklist is our guidance, assembled from what the advisories do and do not claim.

• Find the dependency. Open each Mendix application in Studio Pro and check its dependencies for the SAML module, then record the module version. Marketplace-delivered modules do not always show up in platform-level inventory, and the exposure follows the module version rather than the runtime version.
• Record the flow configuration. Note whether identity-provider-initiated authentication is enabled, and which binding the application accepts. The replay advisory is explicitly gated on IdP-initiated flows; the signature advisory is gated on "specific SSO configurations" without naming them.
• Map reachability. A shop-floor or campus-network application is a different risk profile from one behind corporate VPN. CISA's recommended practices for this advisory are the standard ones: minimise network exposure, keep control system networks behind firewalls and isolated from business networks, and use secure remote access while recognising that a VPN is only as secure as the devices connected to it.
• Ask what the application can do. The severity of an account hijack is set by the authorisation model behind the login, not by the login itself. An app that can release a work order, clear a quality hold, or record a permit is not the same asset as an app that displays a report.
• Check log asymmetry. For service-provider-initiated flows there should be an authentication request on the application side paired with a response from the identity provider. Compare the two sides rather than trusting either one alone, and treat a successful login with no matching request as an investigation trigger.
• Fix the register format. Store CVE identifier, advisory identifier, advisory version, score and scale together. Five of the fields in this article exist only because one of those was missing.
• Name the owner. Mendix applications are frequently delivered by integrators and then inherited by maintenance or engineering teams. If nobody owns the dependency list, the patch does not get applied regardless of the score.

What to test after you patch

Upgrading an authentication module is not a drop-in operation, and the history in this article gives a concrete reason to verify rather than assume: a fixed version was withdrawn as incomplete. Apply the upgrade on a staging application first, and treat these as the minimum regression checks.

• Service-provider-initiated login succeeds end to end, including deep links into a specific page.
• Identity-provider-initiated login behaves as intended, or is confirmed disabled if you have applied the mitigation for the replay flaw.
• Session invalidation and single logout still terminate the session, rather than leaving the application session alive.
• User provisioning and role mapping still run, since authentication and attribute mapping are commonly coupled in these modules.
• Identity provider certificate rollover still validates, because signature handling is exactly what changed.
• Upgrade paths from older module branches are exercised, not just the latest-to-latest jump.
• The version reported by the running application is re-read after the change, and recorded against the advisory version rather than the ticket.

That last item is the one we would insist on. The gap between "we scheduled the upgrade" and "this application is running V4.2.4" is where incomplete fixes and missed deployments both live.

Why an identity flaw lands on a plant maintenance ticket

CISA tagged this advisory to the Critical Manufacturing sector, and that is not a formality. Low-code platforms in industrial settings are typically used for the applications that sit between the control layer and the people who run it: work order capture, shift handover, permitting and lock-out records, quality holds, inspection routes, equipment inspection checklists, and asset status views. Those are exactly the applications that get single sign-on, because nobody wants a second password on a shop-floor tablet, and single sign-on via SAML is what this module provides.

The blast radius of an account hijack in that context is a judgement call rather than a vendor claim, but it is worth making explicit. An attacker who holds a maintenance engineer's session does not touch a controller. They act through the record layer: closing out a job, clearing a hold, changing an inspection result, or reading which assets are due for intervention. Detection is correspondingly awkward, because the authentication event looks legitimate on the application side. That asymmetry, high impact through a low-privilege-looking path, is why identity defects on operational applications deserve a place in an OT security programme rather than being left to the corporate IT backlog.

There is a second reason this belongs in an industrial publication, and it is uncomfortable. Application-layer defects are not procurement problems. There is no firmware image to schedule, no RMA to raise, no obsolete part to last-time-buy, and no panel downtime window to book. The remediation is a module version bump and a configuration review, which is why these defects get under-prioritised: nothing in the supply chain forces a decision date.

What this changes for spares and for the hardware budget

What a defect like this does change is the value of the compensating controls that CISA recommends and that most plants implement in hardware. "Minimise network exposure" and "keep control system networks behind firewalls and isolated from business networks" translate into specific line items on a cabinet BOM, and those items have the lifecycle characteristics that software remediation does not.

Segmentation is where the identity boundary and the physical network meet. The Siemens 6GK5602-0BA10-2AA3 SCALANCE S602 firewall module is the class of device that implements the isolation CISA is pointing at, and it lives in the same cabinet as the 6GK7443-1EX30-0XE0 CP 443-1 communications processor that puts an S7-300 or S7-400 station on the industrial Ethernet in the first place. The same reasoning applies across brands: an Siemens, ABB, Schneider Electric or Allen-Bradley controller is only as isolated as the network path you leave open to it, and the wider communication modules and network adapters categories are where that path is built.

Engineering access is the other half. An authentication defect in a web application does not stop an operator from walking up to a rack and connecting a laptop, which is why controlled engineering access remains a physical inventory question: the 6ES7972-0CB20-0XA0 USB PC adapter for SIMATIC S7, the 6ES7901-3DB30-0XA0 USB/PPI multi-master cable, and the 5 m MPI cable are the parts that carry a laptop-to-controller session. Program and configuration live on removable media with their own availability risk, which is why S7 micro memory cards and S7-400 RAM memory cards belong on the same spares list as the controllers they serve.

Then there is the installed base, and it is the part that actually drives the MRO consequence. Where a controller line no longer has a vendor patch path, identity and segmentation are not a nice-to-have, they are the only remaining controls, and the hardware has to stay serviceable. That is the argument for holding stock on the PLC and I/O modules, CPU modules and HMI and operator panel lines that keep an ageing machine visible and reachable: a dual-CPU redundant bundle for a line that cannot stop, an S7-1500 power supply, an operator panel with its ITP standard cable, and the fieldbus components that keep the network itself intact, from the PROFIBUS DP master interface module to the S7-400H synchronisation module that holds a redundant pair in step. Signal-level parts matter for the same reason: an isolated analog input module or a 32-channel digital input module failing is what turns a maintenance record into a production stop.

Drives and machine controls sit in the same category, since a patched login does not restart a failed power stack. We list VFD and drive components such as the SINAMICS CU240E-2 PN-F control unit, the CU240E-2 DP-F variant, the SINAMICS V20 2.2 kW drive and the TM31 terminal module, alongside machine-side parts like the SINUMERIK 880 PLC CPU module, and PC-side connectivity such as the CP 1623 PCI Express card with its PS791-2AC power supply. Functional-safety components in the safety and protection category follow the same logic in reverse: those are the ones you must never improvise a substitute for.

To be explicit about scope, because we sell parts rather than software: we do not supply Mendix licences, modules or development services, and we do not carry a Mendix support offering. What we stock is the hardware side of the defence-in-depth argument, and what this article is for is making sure the software side gets recorded accurately enough to be actioned.

How this connects to the compliance clock

The European Commission's Cyber Resilience Act pulled its vulnerability reporting obligations forward to 11 September 2026, eight weeks before this Mendix pair landed, and full conformity applies from 11 December 2027. We covered the reporting windows and the OEM consequences in our piece on Rockwell's SecureOT release and the machinery regulation, so this is the short version of what a case like this adds.

Two features of these advisories are exactly the evidence a regulator's mental model expects. A vendor disclosed a vulnerability, shipped a fix, and then re-issued the advisory eight weeks later to say the first fix was incomplete; and a second, related defect in the same component was disclosed separately with a different score and a different weakness class. That is a functioning vulnerability-handling process, including the part nobody advertises, which is the revision. The obligation that bites for anyone operating these applications is the simpler one: knowing which module version is running where, and being able to say when it changed. Our look at the U.S. cyber strategy and legacy PLC spares covers the same problem from the installed-base end, and product-level security standards such as IEC 62443-4-2, which appear in announcements like CompactLogix 5390, are the procurement-side counterpart.

For the wider release this advisory arrived in, see our roundup of the 29 October ICS release, which covers the Hitachi Energy TRO600 and CoreTec advisories alongside the Mendix replay flaw, and the deep dive on CVE-2026-106087, the TRO600 missing-authentication file read. Siemens' platform direction, which is where low-code increasingly sits in industrial stacks, is covered in our report from CIIE and in the divergence between Siemens, Schneider and ABB.

Frequently asked questions

Is CVE-2026-80465 the same flaw as CVE-2026-89209?

No. They are two separate reports against the same Mendix SAML module. CVE-2026-80465 is an account hijacking issue in how the module validates the signature on a SAML response, scored 8.8 on CVSS v4.0 and 8.7 on CVSS v3.1. CVE-2026-89209 is an authentication bypass through replay of an identity provider initiated assertion, scored 6.8 on CVSS v3.1 and 7.6 on CVSS v4.0. Siemens published the two advisories a month apart and both are remediated by the same module builds.

Why does one vulnerability show both 8.8 and 8.7?

The advisory carries two scoring standards side by side. The CVSS v4.0 vector scores 8.8 and the v3.1 vector scores 8.7 for the same defect, because v4.0 changed how user interaction and attack requirements are weighted. A summary that quotes only one of the two numbers is not wrong, it is incomplete. The two versions also disagree about impact: the v4.0 vector lists no availability impact, while scope changes across both, which is why a severity-only comparison between the two CVEs misleads.

Which Mendix SAML module versions are affected?

Every release below V4.2.4 for applications on Mendix 10 and Mendix 11, and below V3.6.29 for releases compatible with Mendix 9.24. The upgrade target cited in several summaries, V4.2.3, sits inside the affected range rather than outside it. A version check therefore has to confirm 4.2.4 or newer, or 3.6.29 or newer on the older platform line, and not treat any 4.2 point release as sufficient.

Do I have to change my identity provider settings?

For CVE-2026-80465 the advisory lists no configuration workaround, only the updated module. For CVE-2026-89209 it lists one: disable identity provider initiated single sign-on. That is a real change on the provider side, and it can break any application where users start at the provider portal and land in the Mendix app, rather than signing in from the Mendix app first. Test the change against every entry point before applying it to production.

How do I find out whether our Mendix application uses the module?

Open the application in Mendix Studio Pro and check the project dependency list for the SAML module, or inspect the packaged mda file, which records every module and its version. If a build server publishes the application, the build log contains the same list. Applications maintained by a supplier or a systems integrator may need a written confirmation of the module version rather than an internal check, because the dependency is not always visible from the running system.

Is either flaw known to be exploited in the wild?

Neither CVE-2026-80465 nor CVE-2026-89209 appears in the CISA Known Exploited Vulnerabilities catalog as of its 29 October 2026 release, which listed 1,764 entries at that time. Absence from the catalog is not a clean bill of health. The catalog tracks confirmed exploitation, and a signature validation defect in a low-code platform used for maintenance and workflow screens is the kind of flaw that is typically disclosed and patched well before public exploitation reports arrive.

Sources

All primary documents were fetched on 30 October 2026 and returned HTTP 200 unless noted.

• Siemens ProductCERT, SSA-887643, "Account Hijacking Vulnerability in Mendix SAML module", V1.1, publication date 3 September 2026, last update 26 October 2026. cert-portal.siemens.com/productcert/html/ssa-887643.html
• Siemens ProductCERT, SSA-137528, "Authentication Bypass Vulnerability in Mendix SAML module", V1.0, 26 October 2026. cert-portal.siemens.com/productcert/html/ssa-137528.html
• CISA, ICS Advisory ICSA-26-302-01, "Siemens Mendix SAML Module", released 29 October 2026, including its revision history and recommended practices. www.cisa.gov/news-events/ics-advisories/icsa-26-302-01
• CISA, ICS Advisory ICSA-26-209-02, "Siemens Mendix Runtime (Update A)", last revised 24 September 2026, revoked. www.cisa.gov/news-events/ics-advisories/icsa-26-209-02
• NVD records for CVE-2026-80465, CVE-2026-89209, CVE-2026-7891, CVE-2025-40758, CVE-2023-29129, CVE-2023-25957, CVE-2022-44457, CVE-2022-37011, CVE-2022-32285 and CVE-2021-33712. Both 2026 Mendix entries were still marked Deferred by NVD at the time of writing, meaning the metrics quoted here are the CNA values from Siemens rather than NVD enrichments. nvd.nist.gov
• Mendix release notes, security advisories index, which lists the SAML module entries reproduced in the recurrence table with their CVSS v3.1 base scores. docs.mendix.com/releasenotes/security-advisories/ — note that this index did not yet list CVE-2026-89209 when we fetched it.
• CISA Known Exploited Vulnerabilities catalog, version 2026.10.29, released 29 October 2026 at 19:09 UTC, 1,764 entries. www.cisa.gov/safeguarding/vulnerabilities
• Siemens Market Place component page referenced by both advisories as the remediation source for the SAML module.

One gap we could not close: the archived earlier revision of SSA-887643 was unavailable when we checked, so we cannot name the fixed version that V1.0 recommended before it was superseded. We have not guessed at it. Reachability of vendor portals from your own network may differ, and the Siemens certification portal in particular is served through a content delivery network that occasionally blocks datacenter address ranges.

Talk to us

If you are holding Siemens controllers, drives, operator panels or the communication and segmentation hardware that protects them, and you want availability confirmed against a specific machine before your next shutdown, send us the model numbers through our contact page. We will quote lead times and, where a part is obsolete, tell you plainly rather than selling you a substitute. For the wider picture, browse the industry news archive, the industry section, or the blog index.