iSTAR TLS Certificate Expiry: Quick Mitigations and TLS 1.3 Migration

Johnson Controls has warned that a certificate-handling flaw in several iSTAR door‑controller families can leave panels unable to restore host communication after the default TLS certificate expires — a failure that impacts availability rather than enabling obvious data theft, but which nevertheless carries significant operational risk for facilities that rely on continuous access-control connectivity. The vendor and CISA provide mitigation options ranging from an immediate host‑certificate swap to a phased migration to TLS 1.3 or — where practical — hardware replacement for legacy panels. The advisory package describes the problem as an improper validation of certificate expiration (assigned identifier CVE‑2025‑61736 in the CSAF the vendor shared), with CVSS scores calculated in both v3.1 and v4 models; operators are urged to treat this as a live operational issue that requires coordination between security teams, integrators and building operations staff. Key vendor guidance and the canonical CISA advisories for related iSTAR issues are available on Johnson Controls’ Product Security Advisory pages and CISA’s ICS advisory pages.

---

Background / overview​

iSTAR controllers — the Software House family used in C•CURE access-control deployments — run across a huge variety of commercial, government and industrial sites worldwide. Variant names in the ecosystem include iSTAR eX, iSTAR Edge, iSTAR Ultra, iSTAR Ultra LT and the newer G2 generation controllers. These devices act as door controllers and edge access nodes that maintain TLS connections to C•CURE servers and use certificates either supplied by the host (C•CURE) or the panel’s default certificate to authenticate and encrypt communications.
Multiple recent advisories affecting iSTAR components — including the iSTAR Configuration Utility (ICU) and separate advisories for iSTAR Ultra / G2 models — underline how certificate handling, firmware verification and edge authentication are recurring themes in the product family’s security posture. Johnson Controls has published product security advisories and CISA has republished several iSTAR advisories; those documents show the vendor is actively coordinating fixes and mitigations for multiple, distinct issues that have appeared across the ecosystem.

---

What the new certificate‑expiration finding actually says​

Executive technical summary​

• Vulnerability class: Improper Validation of Certificate Expiration (CWE‑295 / certificate validation error).
• Affected units: iSTAR eX, iSTAR Edge, iSTAR Ultra LT, iSTAR Ultra, iSTAR Ultra SE — specifically when those devices are configured to use their default certificate to connect to a C•CURE server (the CSAF notes that certain models running TLS 1.2 are affected while G2/TLS 1.3-capable units may have different options).
• Primary operational impact: loss of ability to re‑establish communications with the host once the certificate expires, producing availability issues for the access‑control system.
• Attacker model: Not primarily a remote code‑execution or credential-theft hole — the condition describes improper certificate-expiration handling that can break the TLS handshake and leave panels offline until certificates are updated or connections reconfigured.
• Scores reported in the CSAF you received: CVSS v3.1 base 6.5 (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and CVSS v4 base 7.1. The vendor states the vulnerability is not remotely exploitable in the sense of being a pre-auth remote RCE; instead it presents a local/adjacent availability problem where the panel fails to recover after certificate validity lapses.

This behaviour is operationally meaningful because an unattended expiration can be silently fatal to an access-control cluster: panels that stop talking to the host may still perform locally cached functions, but their lack of server connectivity undermines remote alarms, logging, policy updates and central auditing — producing a real business‑risk even without direct data exfiltration. The distinction between confidentiality and availability impact is crucial here: this finding is about availability and recovery, not about immediate credential theft. The broader advisory suite from the vendor and CISA — including related firmwares and migration guides — frames the issue as both a short‑term operational risk and part of a longer roadmap to more modern TLS/authentication practices across the product family.

---

Verification and what we could cross‑check​

• Johnson Controls maintains a public list of product security advisories and has published multiple iSTAR advisories and updates. The vendor’s security page lists ICU advisories and iSTAR door‑controller advisories as part of its 2025 advisory calendar. Operators should consult that vendor portal for the authoritative mitigation steps and downloadable fixes.
• CISA has republished iSTAR‑related advisories (for example, the iSTAR ICU advisory and separate iSTAR Ultra advisories) and provides standard ICS mitigations and operational guidance. These CISA republished pages are a useful, independent cross‑check of vendor recommendations and of the impact statements that surround iSTAR security issues.
• Independent CERT and security outlets (community CERT postings, industry write‑ups) have summarized Johnson Controls’ iSTAR advisories and the vendor-issued firmware updates (for example, the fix branches that introduced firmware 6.9.3 and ICU 6.9.5). These secondary writeups corroborate the vendor timeline and mitigation channels.

Cautionary note about identifiers: the CSAF you supplied states the issue has been assigned CVE‑2025‑61736. At the time of this reporting, that specific CVE identifier could not be located in public NVD/CVE index pages during verification checks — while CISA and Johnson Controls have published advisories about multiple iSTAR issues, the exact CVE string mentioned in the supplied CSAF did not appear in the public CVE/NVD feeds we queried. Treat the CVE assignment in the CSAF as vendor-provided; confirm the canonical CVE/NVD entry and any vendor release notes before declaring a remediation complete. If your compliance processes depend on a CVE or NVD reference, make that confirmation step explicit in your workflow. (Where possible, obtain the vendor advisory PDF or contact Johnson Controls Trust Center for the definitive CVE mapping.

---

Why this breaks things: a technical look at certificate expiration and handshake recovery​

TLS handshakes rely on correct certificate validation. In typical iSTAR deployments the panel will:

• Use either a vendor‑supplied default certificate or a host‑provisioned certificate.
• Initiate a TLS session to the C•CURE server (or via a gateway such as stunnel / TLS proxy).
• Validate the peer certificate chain, check expiry, and accept the session if all checks pass.

If the panel or the host fails to properly validate certificate expiration — or, conversely, validates expiration but fails to trigger a robust re‑provisioning flow — two failure modes appear:

• Passive failure: the handshake is refused and the panel remains offline until a human replaces the expired cert or reconfigures the device.
• Recovery failure: the software rejects an expired cert and does not attempt or cannot accept the host’s new certificate (for example because the code assumes the default cert will only be rotated manually), so the panel never re‑establishes the channel.

The vendor advisory describes the latter — a condition where, under specific circumstances, a panel using the default certificate cannot re‑negotiate a working connection after expiry, producing persistent communication loss until a mass certificate rollout or a significant configuration change is applied. This is not a man‑in‑the‑middle exploit per se, but rather an availability bug caused by improper validation and recovery logic in the TLS handling and certificate management code path. The operational impact is amplified in systems with many distributed panels and centralized certificate distribution mechanisms that expect rolling re‑enrollment to succeed automatically.

---

Mitigations — vendor recommendations and practical trade‑offs​

Johnson Controls and CISA have published overlapping mitigation guidance. The vendor outlines three primary remediation strategies; each has practical trade‑offs that operations teams must weigh.

• Host‑based certificates (recommended as the quickest solution)
• What: Replace default panel certificates with host‑issued certificates so panels will not rely on their default cert’s lifetime for TLS authentication.
• Pros: No firmware upgrade required in many cases; immediate restoration of correct certificate lifecycle management; relatively small code path changes.
• Cons: Requires simultaneous distribution of new certificates to all panels in scope — this typically requires a planned maintenance window and brief system downtime while the certificates are installed. Operationally complex in large estates unless you have automation and integrator support.
• When to use: Fast remediation when a capable PKI and integrator are available to push certs to many panels at once.
• Convert to TLS 1.3 (cluster‑by‑cluster phased migration)
• What: Migrate clusters to TLS 1.3, which simplifies some certificate handling and modernizes the handshake stack.
• Requirements: Firmware 6.9.0 or higher (per vendor), plus C•CURE 9000 v2.90 SP3 or higher to enable TLS 1.3 support on the server side.
• Pros: Enables phased, cluster‑based migration with lower immediate downtime and stronger cryptography going forward.
• Cons: Not all legacy panels (notably iSTAR eX, iSTAR Edge, and iSTAR Ultra LT) support TLS 1.3; firmware and server upgrades are required; careful testing needed to ensure compatibility with existing stunnel or gateway configurations.
• When to use: Medium‑term remediation for organizations that can schedule firmware and C•CURE upgrades and want a modern TLS baseline.
• Upgrade legacy hardware to G2 units (recommended for very small systems or when time constraints require hardware replacement)
• What: Replace older generation panels that do not support modern TLS and certificate management with second‑generation (G2) hardware that supports TLS 1.3 and improved key management features.
• Pros: Long‑term fix; reduces future migration and vulnerability surface.
• Cons: Hardware costs, physical replacement effort, and system re‑commissioning time — often impractical for large deployments.
• When to use: Small, constrained, or end‑of‑life deployments where firmware remediation is not possible.

CISA’s standard ICS mitigations also apply while remediation is underway:

• Minimize network exposure for panels; do not expose controller management ports to the internet.
• Place panels, jump hosts and C•CURE servers behind segmented firewalls and restrict access to specific management hosts.
• Use secure remote access mechanisms (VPNs, jump hosts) with the caveat that VPNs must be updated and hardened.
• Conduct impact and risk analysis before applying changes to mission‑critical physical security systems.

---

A prioritized operational checklist — what to do now​

• Inventory
• Identify all iSTAR controllers (model, firmware, TLS mode) and their cluster membership.
• Identify C•CURE server versions and stunnel/TLS proxy versions that handle panel communications.
• Short‑term containment (0–48 hours)
• Block panel management ports on the internet-facing firewall.
• Ensure only hardened jump hosts / bastion nodes can reach management interfaces.
• If a cluster uses the default certificate and expiry is imminent, prepare an emergency mass cert‑replacement window with the integrator.
• Quick remedial action (days)
• If feasible, push host‑based certificates to controllers simultaneously (expect a brief downtime window).
• Where host‑based certs cannot be immediately rolled out, schedule controlled firmware upgrades/testing for TLS 1.3 migration for clusters that meet the firmware and C•CURE prerequisites.
• Medium term (weeks)
• Plan cluster‑by‑cluster TLS 1.3 migrations where supported (firmware 6.9.0+ required plus C•CURE 9000 v2.90 SP3+).
• For unsupported legacy models, evaluate a staged hardware replacement plan or extended compensating controls (micro‑segmentation, access restrictions).
• Validation and monitoring
• Confirm TLS handshakes succeed post-change and monitor for failed reconnections.
• Add alerts for “panel offline” and failed certificate validation events.
• Validate certificate rotation processes and automated renewal if host‑issued certificates are used.
• Governance
• Coordinate with the Software House integrator and Johnson Controls Trust Center for vendor-supplied scripts, migration guides and webinars.
• Keep a change log and test in a lab environment before mass rollouts.

This checklist balances speed with safety: the host‑certificate swap is the fastest way to prevent a future expiration outage, while TLS 1.3 migration is more sustainable but requires planning and compatible firmware. Vendor technical documentation and integrator help are essential for safe execution.

---

Detection, monitoring and incident response guidance​

• Monitoring:
• Add specific telemetry for TLS handshake failures and certificate validation errors on the C•CURE server and on stunnel/TLS proxies.
• Watch the panel‑side logs for certificate expiry warnings and for gaps in re‑enrollment activity.
• Detection rules:
• IDS/IPS rules for unusual TLS handshakes or repeated handshake failures from known panel IP ranges.
• SIEM alerts for significant or correlated “panels offline” events across multiple doors.
• Incident response:
• If a cluster goes offline after a certificate expiry, do not perform hasty mass reboots — follow the tested certificate-replacement procedure from the vendor.
• Preserve logs (server and panel logs) for forensic review; record exact timestamps when the certificate expired and when reconnection attempts occurred.
• Communication:
• Prepare an incident advisory for building operations and front-line staff describing likely short‑term impacts (e.g., remote monitoring offline, local caching behaviour).
• Use maintenance windows for certificate rollouts and provide fallback access methods (escorted access protocols) for facilities that rely on central connectivity for door granting until the cluster is restored.

---

Risk analysis — why this matters to Windows/IT teams and security leadership​

• Availability equals safety in PACS environments. Even if panels continue to operate locally, loss of server connectivity can break alarms, audits and operator visibility. IT and security teams must treat these events as operational risk that can escalate to physical safety and regulatory compliance issues.
• Certificate lifecycle automation is under‑engineered in many OT ecosystems. This advisory is another reminder that modern PKI and automated certificate renewal (short‑lived certs, ACME-style automation or tightly integrated host‑based PKI) belong in OT design, not just in IT.
• Short windows of downtime vs long windows of exposure: Host certificate replacement usually needs a short coordinated downtime but quickly removes the expiry risk; delaying fixes in favor of piecemeal firewall rules increases the blast radius if the environment is otherwise exposed.
• Resource and skill gaps: Many organizations rely on integrators for iSTAR lifecycle work. Ensure contracts and support agreements include certified integrator assistance for mass certificate replacement and TLS migrations.

---

Strengths, limits and open questions (critical analysis)​

Strengths in the vendor and government response

• Johnson Controls has published multiple advisories and made firmware updates available (for example, firmware 6.9.3 for Ultra family issues and ICU updates), and the vendor is actively advising integrators and hosting webinars and documentation on the Trust Center.
• CISA’s republication of iSTAR advisories gives operators a clear secondary channel for mitigations and cross‑domain guidance.

Limits and operational friction

• Host‑based certificate distribution at scale is operationally disruptive. The recommended “simultaneous download to all panels” is an effective but blunt instrument that requires careful planning and robust rollback/testing.
• TLS 1.3 migration is attractive but depends on matching firmware and C•CURE versions; not all legacy panels support it. That partial support creates heterogeneity and potential migration windows where mixed TLS stacks complicate operation.

Unverifiable or unclear items (flagged)

• The CSAF you supplied references CVE‑2025‑61736. At the time of writing, that CVE identifier was not visible in the public CVE/NVD feeds we queried; treat the CVE string as vendor-provided until confirmed via the CVE/NVD or the vendor’s definitive advisory PDF. This matters for compliance processes that depend on canonical CVE tracking.
• Exact procedural scripts and in‑field toolkits for mass cert replacement are typically provided to integrators via vendor portals; ensure you request those artifacts from Johnson Controls before beginning mass operations.

---

Recommendations — a pragmatic roadmap for operators​

• Short term (immediate)
• Inventory all controllers and mark those using the default certificate.
• If certificate expiry is imminent, schedule an emergency maintenance window with the integrator to push host‑based certificates to all impacted panels.
• Block public access to panel management ports and limit remote access to hardened jump hosts.
• Medium term (30–90 days)
• Plan and test TLS 1.3 migration for clusters that meet firmware and C•CURE prerequisites (firmware 6.9.0+, C•CURE v2.90 SP3+).
• Automate certificate renewal where possible and integrate certificate monitoring into your network monitoring stack.
• Long term (policy)
• Treat certificate lifecycle and PKI as first‑class OT concerns: include rotation plans, automated renewal and documented emergency rollbacks in OT change‑control processes.
• Schedule lifecycle upgrades for legacy panels that cannot support modern TLS; consider G2 upgrades for small, high‑risk sites.
• Governance & people
• Update runbooks and escalation paths; ensure integrators are on retainer and known to SOC/IR teams.
• Exercise tabletop scenarios where panels lose host connectivity due to certificate expiry and validate the operational fallback plans.

---

Final assessment​

The Johnson Controls iSTAR certificate‑expiration issue is not a classic remote‑code or credential theft exploitation; it is an availability and recovery failure that can have outsized operational effects in physical access systems. The vendor’s pragmatic mitigations — host certificates for immediate relief, TLS 1.3 for phased modernization, and hardware upgrades for legacy units — offer a sensible menu, but each option carries real scheduling, testing and cost trade‑offs. Organizations that operate iSTAR panels must treat certificate lifecycle management as an operational imperative: inventory, coordinate with integrators, plan short maintenance windows for certificate installs, and adopt a modern PKI/TLS posture as soon as practical.
Verify CVE mappings and follow the vendor’s product security advisory pages and CISA notices for the latest, authoritative instructions before performing mass changes; if a formal CVE reference or NVD entry is a requirement for your change control, confirm that identifier with the vendor and your compliance team.

---

Appendix: quick reference (one‑page action list)

• Immediately: inventory iSTAR models + certificate sources.
• Next 48 hours: block internet access to panels; restrict management to bastions.
• Within 7 days: coordinate host‑certificate rollout with integrator (expect brief downtime).
• Within 30–90 days: test/plan TLS 1.3 cluster migrations where firmware + C•CURE prerequisites allow.
• Ongoing: implement automated certificate monitoring and renewal; maintain vendor support contracts; practice incident playbooks for offline panels.

(See Johnson Controls product security advisories and the CISA ICS pages for vendor‑issued procedures and recommended configuration steps.

---

Source: CISA Johnson Controls iSTAR | CISA