# How to manage an IT or EHR vendor's remote access to your practice Sign a BAA with the vendor, list every way it connects in, give each technician their own login with MFA, and review what they did in your systems. Updated: October 16, 2026 An IT company or EHR vendor that maintains your systems from outside your office is a business associate under HIPAA when the work involves patient data. So start with a business associate agreement (BAA). Then manage the access itself: know every way the vendor connects in, give each technician their own login with a second check at sign-in, and review what they did. ## When a maintenance vendor is a business associate HHS's business associate guidance gives two examples that fit maintenance work. One is an IT contractor or vendor, such as an EHR vendor or a managed services provider. It counts when maintaining or supporting your systems requires it to create, receive, keep or send patient data. The guidance says this applies whether the work is done in person or remotely. The other is a technician who services a device that stores patient data, like a copier or a medical device, when the service exposes that data. The agreement has to meet 45 CFR 164.314(a). The vendor must comply with the Security Rule, require the same of its subcontractors, and report any security incident it becomes aware of. Someone whose work doesn't involve patient data, such as an electrician, doesn't need a BAA. That holds as long as any contact with the data is incidental and you have reasonable safeguards in place. ## Why remote access needs extra care Remote access tools let a vendor's technician see and control your computers from anywhere. CISA's Guide to Securing Remote Access Software, written with the NSA, the FBI and others, explains why attackers like the same tools. Remote access software is used for legitimate work, so security software often doesn't flag it. And an attacker who breaks into a managed services provider may reach many of its customers at once. HHS's 405(d) guide for small healthcare organizations makes a related point about medical devices. Many are managed remotely by outside vendors, and the guide says that widens the area an attacker can target. ## List every way vendors connect in You can't control a connection you don't know about. So start with a list: which vendor connects to which system, with which tool, from where. CISA recommends auditing the remote access software installed on your devices to find out which tools are in use and which are authorized. The 405(d) guide says to check that remote access software on your computers is still in use. It also says to disable inbound Remote Desktop Protocol (RDP), the Windows remote control feature, which it calls a common attack route. Instead, set up a VPN (a private, encrypted connection) for the specific people and systems that need remote access. Ask each vendor directly what it has installed, and compare its answer with what you find on your devices. HHS's voluntary Cybersecurity Performance Goals for the health sector include an asset inventory among the enhanced goals. Your list of vendor connections can be part of it. ## Give each technician their own login The Security Rule requires a unique name or number for each user of a system that holds patient data (45 CFR 164.312(a)(2)(i), "Required"). A vendor login that the whole support team shares breaks that link. Your system's record shows the login, not which technician used it. The other guidance points the same way: - HHS's Cybersecurity Performance Goals list "Unique Credentials" and separate accounts for admin work among the essential goals. Unique credentials help you spot unusual activity and keep an attacker from moving between systems. - The 405(d) guide says to create a separate admin account for each person who needs admin rights. It also says to turn on MFA (multi-factor authentication: a second check after the password) for every admin account and every VPN connection. - CISA tells managed services providers to use MFA on every account that can reach a customer's systems and to treat those accounts as privileged. It also says not to reuse admin passwords across customers. The current Security Rule requires procedures to verify that a person signing in is who they claim to be (164.312(d)), but it doesn't name MFA. In January 2025, HHS proposed requiring MFA, with limited exceptions. That rule has not been finalized. For a vendor login that has to stay shared for now, see [What to check when a vendor says its team uses one shared login](/guides/outsourcing-access/when-contractor-uses-shared-id). ## Review what the vendor did Reviewing activity in your systems is your practice's job. The Security Rule requires you to have ways to record and examine activity in systems with patient data (164.312(b), audit controls). It also requires you to review those records regularly, such as audit logs and access reports (164.308(a)(1)(ii)(D), "Required"). Log-in monitoring (164.308(a)(5)(ii)(C)) is "Addressable". You put it in place if it's reasonable for your practice. If not, you document why and use an equivalent measure where one is reasonable (164.306(d)(3)). Some of the record may sit with the vendor rather than in your systems. CISA says customers of managed services providers should make the contract require visibility into the provider's presence, activities and connections in the customer's systems. It also says to keep the ability to delete or change logs out of reach of remote access tools. Compare each connection against the work you approved, such as the ticket or the maintenance window. ## What to put in the contract The BAA covers the HIPAA minimum. A maintenance contract is where you set the operating details. CISA advises customers to understand exactly which security services the provider delivers and to cover anything outside that scope. It also says the contract should state how and when the provider will tell you about an incident affecting your systems. The HHS goals include vendor cybersecurity requirements as an essential goal and third-party incident reporting as an enhanced one. The 405(d) guide adds what to check during the contract and at its end. You can ask for the vendor's security policies, proof of staff training, background checks and risk assessments. The contract should also say how all of the vendor's access will be removed and documented when it ends, and how patient data will be returned or destroyed. In practice, that means removing the vendor's logins, uninstalling its remote access tools, and closing any VPN accounts it used. The [checklist for taking back access when a vendor contract ends](/guides/outsourcing-access/access-recovery-at-contract-end) gives the order. ## Frequently asked questions **Does our EHR vendor need a BAA to give us remote support?** If its support work means creating, receiving, keeping or sending patient data, yes. HHS lists IT and EHR vendors that maintain systems, in person or remotely, as examples of business associates. **Can the vendor's technicians share one admin login to our system?** Avoid it. The Security Rule requires a unique name or number for each user, so a system's record can tie each action to a person. HHS's 405(d) guide also says to give each user their own account. **Does HIPAA require MFA for vendor remote access?** The current Security Rule doesn't name MFA. HHS's voluntary performance goals list it as an essential goal for internet-facing access. HHS has proposed making MFA a requirement, but that rule is not final. **Who reviews what the vendor did in our systems?** Your practice. The Security Rule requires you to review records of system activity regularly. Your contract should require the vendor to give you the records of its own connections and actions. ## Sources - [45 CFR 164.308, Administrative safeguards (eCFR)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308) - [45 CFR 164.312, Technical safeguards (eCFR)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312) - [45 CFR 164.314, Organizational requirements (eCFR)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.314) - [HHS: Business Associates](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html) - [HHS: Healthcare and Public Health Sector-Specific Cybersecurity Performance Goals](https://hhscyber.hhs.gov/cybersecurity-performance-goals.html) - [HHS 405(d): Technical Volume 1, Cybersecurity Practices for Small Healthcare Organizations (2023 Edition)](https://hhscyber.hhs.gov/Documents/HICP/tech-vol1-508.pdf) - [CISA and partners: Guide to Securing Remote Access Software (June 6, 2023)](https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software) - [45 CFR 164.306, Security standards: General rules (eCFR)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306) - [Federal Register: HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule, January 6, 2025)](https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information) - [HHS: HIPAA Security Rule Notice of Proposed Rulemaking fact sheet](https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html) ## How Junify handles this **Doing this by hand** You give every clinician and staff member their own login, open and close access for each per-diem shift and vendor staff change, and keep a record of who used which system and when for someone to review. **With Junify** For maintenance done in a web admin console, your admin can change that login's password at setup and keep it only in Junify. Each technician verifies on their own phone before signing in, so you can see who signed in and when without asking the vendor. With recording on, if something goes wrong you can see on screen what the technician did. Remove a technician's assignment and they can't sign in. VPN and server logins aren't covered. Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when. - [Try the demo](https://www.junify.com/bpo/try?lang=en&scenario=healthcare&from=guide&cluster=healthcare-access&slug=remote-maintenance-vendor-access) - [Book a 30-minute demo](https://www.junify.com/bpo/demo) ## More on this topic - [Can staff use personal devices to access clinical systems?](/guides/healthcare-access/byod-for-clinical-systems): HIPAA allows it with safeguards. Treat each personal laptop or phone as a workstation, write a device policy, and protect both the device and the login. - [Who is responsible for user accounts in your practice's cloud software?](/guides/healthcare-access/clinic-saas-responsibility-split): The vendor secures its service. Your practice decides who gets a login and removes it when they leave. HHS says to sign a BAA and put the split in writing. - [The HHS cybersecurity performance goals for accounts and logins](/guides/healthcare-access/hhs-cybersecurity-performance-goals-accounts): Four of HHS's 10 essential goals cover logins: MFA, revoking departing staff's access, unique credentials and separate admin accounts. HHS calls them voluntary.