HSC Winnipeg Ransomware: Secure Break-Glass Access for Building Systems
A ransomware incident at Health Sciences Centre Winnipeg affected door access, heating, ventilation and air-conditioning systems at Manitoba's largest hospital. Shared Health said clinical services continued without interruption and that its investigation had found no indication that patients were affected.
The incident is a sharp reminder that emergency access is not only an IT concern. Credentials for building controls, security systems and maintenance consoles can sit on the path between a cyber incident and physical safety. Organizations need a way to authorize, transfer, use and retire those credentials under pressure without turning an incident chat into a permanent repository of privileged access.
What is confirmed
In a statement provided to CBC News on August 10, Shared Health described a “ransomware incident affecting certain facility maintenance systems.” CBC reported that door access and heating, ventilation and air-conditioning were affected. Shared Health said it was investigating the nature and scope of the incident, reviewing the affected systems and seeking expert assistance.
The health authority said patient care and clinical operations were not affected and urged people who needed care to continue attending the hospital. CBC also reported that HSC increased the presence of security and institutional safety officers at entrances while door systems were affected.
CTV News independently reported the incident and the separation between the affected facility systems and clinical systems. Public reporting does not identify the initial access method, ransomware operator, duration of access or whether any data was taken. It would be speculation to blame an exposed internet service, phishing, an unpatched product or a particular supplier without further evidence.
Why building-system credentials need their own emergency plan
A building management account may control doors, environmental systems or remote maintenance functions. During an outage, responders can need alternate accounts, recovery codes, vendor support credentials or locally held administrator access. If those values are improvised into email, ordinary chat or a shared incident document, they create copies that may remain searchable long after the emergency.
The risk is higher when the organization does not yet know which identities or endpoints are trustworthy. A password pasted into a channel available from a compromised workstation can give the intruder the replacement credential as soon as responders create it. The emergency process therefore needs a clean handoff path, not simply a stronger password.
Build the break-glass process before the incident
- Inventory the consequence, not just the account. Map which credentials can affect doors, HVAC, elevators, alarms, cameras and vendor remote access, and record the operational owner for each system.
- Separate routine administration from emergency access. A break-glass identity should not be the same account used every day or shared by an entire maintenance team.
- Define who may authorize release. Name primary and alternate approvers from facilities, security and incident command so responders do not invent authority during an outage.
- Prepare an independent verification method. Keep a current call tree or another pre-agreed method for verifying the recipient when corporate email or chat cannot be trusted.
- Keep recovery material available through a tested contingency. The authoritative copy belongs in the organization's controlled recovery process, with offline availability where required—not buried in an old chat thread.
- Exercise the full handoff. A tabletop should test authorization, recipient verification, access from a clean device, audit evidence, revocation and rotation after use.
How to hand off a credential during recovery
Start by deciding whether the recipient genuinely needs the secret. Prefer a scoped, temporary identity over disclosing a permanent administrator password. Confirm the person and their incident role through the pre-agreed verification path, then deliver the value through a channel that does not add plaintext to the incident transcript.
- Use the shortest practical validity window and the minimum permissions required for the recovery task.
- Send only the secret value and the minimum context needed to use it; keep architecture diagrams and sensitive recovery notes in their governed locations.
- Record who authorized the transfer, who received it, its purpose and when it was retired—but do not put the secret itself in the audit record.
- Revoke or rotate the credential as soon as the emergency task ends, even if the transfer mechanism was one-time.
- Review logs from the target system to distinguish the authorized recovery session from other activity.
Availability and security have to be designed together
Removing every remote path can make legitimate emergency maintenance impossible; leaving broad standing access can make compromise easier. The answer is a documented trade-off: network segmentation, constrained vendor access, resilient local operation, monitored administrative sessions and a tested route for emergency authorization.
Recovery material also needs an availability decision. An online-only process may be unreachable during a network shutdown, while an unmanaged paper copy may be copied or go missing. Critical facilities should decide which credentials require an offline contingency, how physical copies are controlled and how every copy is replaced after activation.
Where Secretus fits—and where it does not
Secretus can be used for an authorized, ad-hoc handoff of a temporary password, recovery code or scoped token without placing the plaintext value in email or chat. Standard Mode can make the link single-use and short-lived; Team Split can support a pre-designed multi-person release process when the organization's availability model permits it.
Secretus is not a privileged-access management system, a credential vault, an identity verifier or a control for hospital building networks. It cannot make a compromised endpoint safe, guarantee that a copied secret was not recorded or replace offline continuity arrangements. Use it only after authority and recipient identity are established, and rotate the credential after the task.
A focused tabletop for facilities and incident teams
- The normal identity provider and corporate chat are unavailable.
- Door-control administration must be restored from a clean workstation.
- The primary facilities administrator cannot be reached.
- A vendor asks for temporary remote access while the scope of compromise is unknown.
- The exercise ends only after access is revoked, logs are preserved and every exposed recovery value is rotated.
Measure whether the team can identify the right approver, verify the recipient, locate the authoritative recovery material and complete the handoff without pasting a secret into a persistent channel. That is a more useful resilience test than merely confirming that a spare password exists.
