All articles
Healthcare Security Rollouts Succeed When Endpoint Protection Fits Clinical Workflows
Michael Sieli, Project Manager at Main Line Health, explains how he deployed endpoint protection across 11,500 endpoints in a hospital system by staging the rollout around clinical continuity, starting with a controlled IT pilot, and earning organizational trust one clean deployment at a time.

Make The Security Digest one of your go-to sources on Google
You can’t go right into the hospital and do a rollout. You have to test everything out, test your team, evaluate that rollout, and make sure there’s no hiccup.
Deploying endpoint protection across a banking environment and deploying it across a hospital system are fundamentally different operations. In banking, users are generally adept with technology. In healthcare, clinicians are focused on patients. They're not interested in security tooling, and they will push back the moment it touches their workflow. That difference shapes everything about how a healthcare security deployment has to be designed: uptime, user choice, rollout sequencing, and staged trust-building matter as much as the endpoint protection itself.
Michael Sieli is a Project Manager with a lengthy history of leading telecom, network, and cybersecurity deployments in the healthcare, telecommunications and banking industries. His project management work spans Bank of America, Citibank, and AT&T, in addition to multiple hospitals and health systems. He's learned that in healthcare, the first clean deployment determines whether the organization will let you finish. "You can't go right into the hospital and do a rollout," Sieli says. "You have to test everything out, test your team, evaluate that rollout, and make sure there's no hiccup."
Start with a win
One of Sieli's recent projects was a behavioral endpoint protection rollout across 11,500 endpoints, which he worked on with Security Program Manager Tony Fiore and CISO Aaron Weismann. Their first step was standardization. "We had boxes that were Windows 2008. We had to get everything on the same platform before we could roll it out." The pilot targeted 500 IT department users, a deliberate choice rather than a random sample. "They're IT users, so they have more leeway of understanding," Sieli says. "Once we did that and it was clean, we knew we could start rolling this out." The team waited two weeks after the pilot to confirm there were no issues before expanding. From there, the rollout moved through auxiliary facilities, rehab centers, and outpatient buildings, building confidence at each stage before touching the main hospitals.
"You want to get a win," Sieli says. "The organization, especially in healthcare, is going to say 'this is a mistake.' The first rollout has to come clean."
Separate the hard from the easy
Sieli divided the deployment into three categories: laptops, workstations, and servers. Laptops were the fastest. Packages were pushed overnight, with employees asked to leave machines online. When they powered up the next morning, the agent was already installed. Users who were online during the day received a prompt with the option to reboot immediately or delay. "You have to give people options," Sieli notes. "There may be something really important they have to do."
The team identified gaps quickly. For instance, remote workers not connected to VPN missed the initial push. Those lessons learned fed back into the next wave. Laptops and workstations were completed in four months. Servers, the most operationally sensitive layer, took an additional two and a half months because each one sat underneath clinical applications with integration dependencies that required careful validation.
Protect trust after the rollout
Even a clean deployment can be tested after the fact. After the endpoint agent was deployed on a cardiology system, the application went down three days later. The timing created immediate concern, and the clinical director called an emergency meeting to understand whether the new security tool had affected the system. "We got everybody on the call," Sieli recalls. "CrowdStrike said, 'this is what we’ve got and it’s not us.'" The application team later confirmed the failure originated elsewhere.
For Sieli, the lesson was not that clinical teams resist security for the sake of resisting it. It was that healthcare systems sit too close to patient care for any disruption to be treated casually. When an application goes down after a security change, the security team has to expect scrutiny and be ready with evidence, escalation paths, and vendor support. "You’re going to get blamed for just being in the area," Sieli says. In that environment, trust is earned through preparation, transparency, and repeated stability.
That makes success look different from a standard endpoint project. Coverage numbers and threat-detection metrics matter, but the operational test is whether clinicians can come to work, log in, and continue caring for patients without noticing the system changed underneath them. "All they know is that they come to work, their machines are working, and they’re logging in with no issue," Sieli says. "As long as there’s uptime and no downtime, it’s a success."






