The Security Gaps Your Medication Dispensing Vendor Installed and Never Mentioned

Disclosure: Parts of this article were contributed by visuaFUSION Systems Solutions.  One vendor referenced in this article - 3AM Technologies - was evaluated during a visuaFUSION client engagement. The contributor also maintains an ongoing professional relationship with 3AM Technologies' leadership. This relationship is disclosed in full. Editorial standards and conclusions are independent.

If your organization uses an automated medication dispensing cabinet or system - and most facilities that store and dispense medications do - there is a reasonable chance it was installed in a way that quietly disabled some of your most important network security controls. Nobody sent you a memo about it. The vendor called it "domain integration" and left you a system that works. Medications dispense. Nurses log in. Everything looks fine.

"Works" and "secure" are not the same thing.

This article is written primarily for health care administrators, CEOs, COOs, and anyone responsible for technology decisions at their organization who may not be deep in the technical details every day. It is also written for IT managers and systems administrators who may have accepted vendor installation instructions at face value and want a framework for re-examining what those instructions actually did.

The goal is simple: by the time you finish reading, you will have six specific questions to bring to your IT team about your medication dispensing systems. The answers will tell you a great deal about your actual security posture - and what, if anything, needs to be addressed.

What "Domain Integration" Actually Means - and Why It Matters

Most health care organizations run their computers on what is called a domain - a centralized system that lets IT staff manage settings, security policies, and user accounts across every computer in the organization from one place. When a new server or workstation is added to that domain, it comes under those centralized controls. Password requirements, account lockout rules, who is allowed to log on to what, what programs can run - all of it flows down to every machine that is properly joined to the domain.

When a medication dispensing vendor says they are "integrating" their system with your domain, the implication is that the system is being brought under those same controls. In practice, that is not always what happens.

Some vendors require a specific step before they will complete the integration: running a utility or script on the medication dispensing server that disables the very mechanism that delivers those security policies to the machine. The system joins the domain in name. It shows up in your Active Directory management console. It can receive some updates. But your security policies - every baseline control your IT team has configured - never actually reach it. They are blocked at the registry level by the vendor's own installation requirement.

The vendor leaves. The installer closes out the ticket. The settings stay.

This is not a theoretical concern. Documentation from at least one major medication dispensing vendor - distributed to customers as recently as late 2025 for their current platform - lays this out explicitly as a required step. A vendor-supplied utility must be run. Confirmation that group policies have been "disabled successfully" must be received before proceeding. It is not a workaround or a shortcut someone improvised in the field. It is the documented, required installation process.

That same documentation also specifies additional requirements that carry their own security implications: local administrative accounts with automatic logon configured on servers and cabinets, antivirus software configured with specific exclusions, and - in a significant number of actual deployments - shared generic administrative credentials used by IT staff for remote access to those servers.

None of that was in the sales brochure.

Six Questions to Ask Your IT Manager

These questions are written so that any administrator can ask them without needing a technical background. Each one explains what you are asking, what a concerning answer looks like, and why it matters - including where federal compliance obligations are directly implicated.

Question 1: Did the vendor require running a script or utility before joining these systems to our domain?

Before the medication dispensing servers or cabinets were added to your network, did the vendor's installation instructions require your IT team to run any program or utility on those machines first? If the answer is yes, what did that program do?

In at least one major vendor's current documentation, the required step before domain joining is running a specific utility that makes permanent changes to the Windows registry. Those changes disable what is called Group Policy processing - the mechanism through which your IT team pushes security settings to Windows machines across your organization. The vendor's own documentation acknowledges this explicitly, noting that simply placing the systems in a protected area of Active Directory is not sufficient protection, and that their utility is required to guarantee that no enterprise security policies ever apply.

Group Policy is how organizations enforce password requirements, account lockout settings, access restrictions, audit logging configuration, and dozens of other security controls across Windows computers. When it is disabled at the registry level on a server, that server operates on whatever local configuration was set at installation time. Your organization's security baseline does not apply to it. Changes your IT team makes to your domain security policies in the future will not reach it. It sits on your domain in name only.

Under 45 CFR 164.308(a)(1)(ii)(A), covered entities are required to conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308). A server where enterprise security policy enforcement has been intentionally and permanently disabled is a risk that belongs in that assessment - with documented compensating controls or a remediation plan. If it is not there, the assessment is not accurate or thorough.

Question 2: Are the medication dispensing systems using local accounts or domain accounts?

When the vendor set up the accounts used to operate these systems, were those accounts created directly on the machines, or are they domain accounts managed through your central Active Directory system?

At least one major vendor's current installation documentation is explicit on this point: local user accounts are required for all logons and service accounts on the medication dispensing systems. Domain authentication for nurses or other clinical staff is not supported under the standard integration model - it requires a separate, purchased integration option.

The practical problem with local accounts is that they exist entirely outside your centralized identity management infrastructure. They are not visible in your Active Directory. They are not subject to your domain password policies. When an employee leaves your organization and your IT team runs your standard offboarding process - disabling the person's domain account - that action has no effect on any local account that person may have had on a medication dispensing server. That account continues to exist until someone manually removes it from each individual machine, which in practice often does not happen on any predictable schedule.

This also has a direct compliance implication. 45 CFR 164.312(a)(2)(i) is a Required implementation specification under the HIPAA Security Rule (https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312). It requires covered entities to assign a unique name and/or number for identifying and tracking user identity. Local accounts that are shared across multiple staff members, used generically, or not tied to a specific individual's identity cannot satisfy this requirement. If you cannot attribute activity on a system to a specific, identifiable person, you cannot meet your audit obligations.

Question 3: Is there an automatic logon configured on these servers or cabinets?

When a medication dispensing server or cabinet is rebooted or starts up, does it automatically log itself in - arriving at a Windows desktop, fully logged in, without anyone having entered a username or password?

At least one major vendor's current documentation explicitly requires this. The language is unambiguous: a local auto logon with administrative privileges is required on both servers and cabinets. This is not presented as an option or a convenience setting. It is listed as a requirement.

Auto logon with administrative privileges means there is no credential barrier between the physical machine and full system access. Anyone who can reach the console of that server - whether by walking up to it, plugging in a keyboard, or connecting to it remotely - has administrative access to the operating system without entering any credentials at all.

For medication dispensing cabinets located in nursing stations, patient care areas, or medication rooms, the narcotics inside the cabinet are protected by the cabinet's lock. The Windows server running underneath may not be protected by anything at all. Physical access to the hardware is, effectively, administrative access to the system. For the server infrastructure supporting those cabinets - which may sit in a network closet or server room - access control to the room itself becomes the only barrier.

Question 4: When your team or the vendor remotely accesses these servers, what account do they use?

When your IT staff needs to remotely connect to a medication dispensing server to troubleshoot, update, or maintain it, is each person using their own individual login credentials? Or is there a single shared username and password that everyone uses?

In a significant number of actual deployments, remote access to medication dispensing servers is handled through a single shared administrative account. All IT staff use the same username and password. Vendor support technicians may use the same credential. Nobody on the team has their own individual account at the operating system level.

This is one of the most direct compliance failures in the entire picture. 45 CFR 164.312(a)(2)(i) - the same Required specification cited above - demands unique user identification (https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312). A shared administrative account is the precise opposite of that requirement.

Beyond compliance, shared accounts eliminate accountability. If something happens on that server - a configuration changed, a file accessed, a service disrupted, logs modified - there is no way to determine which specific person did it. Under 45 CFR 164.312(b), covered entities are required to implement mechanisms that record and examine activity in information systems that contain or use electronic protected health information (https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312). The "examine" part requires that activity be attributable to an individual. Shared accounts make that impossible at the operating system level.

Vendors sometimes argue that access to actual patient data requires logging into the dispensing application itself, which does use individual credentials. That is true as far as it goes. The operating system, however, is still a system that can contain or access electronic protected health information - configuration data, logs, cached information, network connections to other clinical systems. Application-layer authentication does not excuse OS-level shared credentials, and that argument does not hold up under scrutiny in a HIPAA audit context.

Question 5: Did the vendor require antivirus exclusions on these systems?

As part of the installation, did the vendor provide a list of files, folders, or file types that your antivirus or endpoint protection software should be configured to ignore on these machines?

At least one major vendor's current documentation requires exactly this: antivirus clients must be configured to exclude specific files and file types per the vendor's documented list.

Antivirus exclusions are not inherently problematic. Specialized clinical software sometimes generates false positives with aggressive endpoint protection, and targeted exclusions are a legitimate tool in those situations. The concern is not that exclusions exist. The concern is whether they have been reviewed, documented, and kept current.

Exclusions set during an installation three or five years ago, and never revisited since, represent a growing gap in endpoint protection coverage. The threat landscape changes. Malware specifically designed to target paths or file types that have been excluded can run on that system without detection. On a server that controls access to narcotics and may log or transmit protected health information, unreviewed endpoint protection gaps are a material risk.

Your organization should be able to produce documentation of exactly what is excluded on those systems, the business justification for each exclusion, and when those exclusions were last validated against current threat intelligence and the vendor's current recommendations.

Question 6: When did you last receive complete documentation of what the vendor changed - and is it reflected in your risk analysis?

Does your organization have a written record of every configuration change the vendor required when these systems were installed? Registry changes, account configurations, Group Policy disablement, antivirus exclusions, network port openings, remote access setup - all of it. And is that information explicitly part of your most recent HIPAA risk analysis?

This is the broadest question and arguably the most important one. Your organization is responsible for understanding the security posture of every system on your network that creates, receives, maintains, or transmits electronic protected health information. That responsibility does not transfer to the vendor because the vendor provided the installation instructions.

Under 45 CFR 164.308(a)(1)(ii)(A), the risk analysis must be an accurate and thorough assessment (https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308). If your risk analysis does not reflect the actual configuration of your medication dispensing systems - including every vendor-required deviation from your standard security baseline - it is not accurate or thorough by definition.

"The vendor handled the installation" is not a compensating control. Documentation is. A written risk analysis that accounts for these configurations, identifies the gaps, and documents how your organization is managing them is.

If Some of Those Answers Concern You

If any of these questions surfaced gaps you were not aware of, you are not alone and you are not looking at a failure unique to your organization. These configurations are frequently the direct result of following vendor instructions as provided. IT staff implementing them are not making independent decisions to weaken security - they are doing what the vendor documentation says is required. The gap is often not in who did the work. It is in what was communicated to leadership about what the work entailed, and what it means for the organization's security posture and compliance obligations.

The path forward is not complicated, but it requires deliberate action.

Start with documentation. Ask your IT team to produce a written summary of the current configuration of your medication dispensing systems - how they connect to your network, what accounts are in use at the operating system level, whether Group Policy applies to them, what antivirus exclusions are configured, and how remote access is handled. If that documentation does not exist or is incomplete, creating it is the first step.

Feed that into your risk analysis. Every deviation from your standard security baseline that the vendor required is a risk to be assessed, documented, and either remediated or compensated for with alternative controls. If you are ever subject to a HIPAA audit or breach investigation, the question will not simply be whether these configurations existed. It will be whether you knew about them, assessed them, and took reasonable documented steps to address them.

Push back on the vendor. Some of these requirements have workable alternatives. Strict network segmentation - isolating medication dispensing systems on their own network segment with tightly controlled firewall rules - can significantly limit the exposure created by disabled Group Policy. Physical access controls reduce the risk of console-level auto logon exposure. Individual technician credentials, even temporary ones provisioned for vendor support access, are a better answer than a shared administrative password that never changes. These conversations are easier to have before a contract is signed than after a system is live. Make security requirements part of your vendor evaluation process, and get commitments in writing.

It is also worth knowing that not every vendor in this space demands these concessions. During a client implementation, the visuaFUSION team deployed a medication dispensing system from 3AM Technologies into a fully locked-down health care network environment - standard user rights, UAC enabled, Windows Firewall on, active antivirus without required exclusions, and monthly patching running through normal channels without issue. Their platform also supports installing the client application directly on workstations, eliminating the need for staff to RDP into a server at all - which removes the shared remote access credential problem entirely. In that engagement, the cost came in at roughly half what comparable quotes from larger established vendors were running for the same client. The visuaFUSION team has an ongoing professional relationship with 3AM Technologies' leadership and can speak to their willingness to work within security-first environments rather than around them. That experience is reflected in the vendor review index below. Not every organization's needs will be the same, and thorough evaluation is always warranted before any purchasing decision - but the point stands clearly: a vendor telling you their system cannot function within your security policies is not necessarily stating a fact. It may simply be reflecting a design choice they have not been pushed to revisit.

Finally, include these systems in your regular security reviews. Medication dispensing servers are clinical systems, but they are also Windows servers sitting on your network. They should not be exempt from your annual risk analysis, your security assessment cycle, or - if your organization conducts them - your penetration testing program. The fact that a system is clinical does not reduce its relevance as an attack target. In some respects, it increases it.

Medication Dispensing Vendor Security Review Index

Over the coming months and years, Health Tech Authority will be conducting security reviews of major automated medication dispensing platforms used in health care organizations. These reviews are grounded in field experience and direct analysis of vendor documentation and integration requirements.

Our review methodology examines domain integration requirements, authentication and account management practices, Group Policy and Windows security baseline compatibility, endpoint protection configuration requirements, remote access procedures, and patch management support.

Reviews will be added to the index below as they are completed. This article will be updated as new reviews are published.