The integration points nobody monitors are the ones attackers exploit first
NIST CSF 2.0 → PROTECT → PR.PS: Platform Security + IDENTIFY → ID.AM: Asset Management
This post is part of our ongoing series mapping real-world healthcare security challenges to the NIST Cybersecurity Framework 2.0. It builds on foundational concepts introduced in The Compliance Trap and Why HIPAA Compliance Isn’t Enough. Where those posts address governance and risk management, this one dives into the technical seams—the API integrations that connect your clinical systems and create silent trust paths attackers can exploit.
Nobody hacked the EHR. Nobody breached the telehealth platform. The attacker walked through the door between them.
A multi-location telehealth practice in the Hudson Valley had all the right pieces in place. Their EHR was SOC 2 certified. Their telehealth platform was HIPAA-compliant. Their billing vendor had passed its most recent audit with flying colors. On paper, the security posture looked solid.
But between the scheduling system and the EHR sat a single API key. It had been hardcoded into a configuration file three years ago when the integration was first set up. It had never been rotated. It had never been audited. And it had full read access to the patient database—because the developer who configured it chose the broadest permission scope to “make sure everything worked.”
When the scheduling vendor experienced a breach, that API key was among the credentials exposed. The attacker didn’t need to break into the EHR. They didn’t need to phish a provider. They simply authenticated through the front door of a legitimate integration—and quietly extracted 23,000 patient records over a two-week period. The activity looked identical to normal scheduling synchronization.
A typical telehealth practice has a web of system-to-system connections that nobody has ever diagrammed. Each arrow below represents an API call. Each API call is a trust boundary. Each trust boundary is a potential attack surface.
EHR ↔ Telehealth Platform
Patient demographics, visit notes, clinical documents. Bidirectional sync runs every 60 seconds. The API key has full read/write access to the patient chart.
Telehealth Platform ↔ Scheduling System
Appointment times, patient contact info, provider availability. Real-time webhook fires on every booking. Service account has access to the entire patient roster.
Scheduling System ↔ EHR
Appointment confirmations, insurance eligibility, patient intake forms. Batch sync runs nightly. Uses a shared credential set up during initial implementation.
EHR ↔ Billing / Clearinghouse
CPT codes, diagnosis codes, patient insurance data, payment info. Claims submitted in real time. API transmits the most financially sensitive data in your practice.
EHR ↔ Lab Systems
Lab orders, results, specimen tracking. HL7/FHIR interface with broad access to clinical data. Often managed by the lab vendor, not your IT team.
EHR ↔ e-Prescribing (eRx)
Medication lists, prescription history, pharmacy routing. NCPDP/SCRIPT standard. Credential management is typically delegated to the eRx vendor.
EHR ↔ Patient Portal
Messages, test results, appointment requests, billing statements. Patient-facing API exposes data to the widest audience—and is the least likely to be monitored.
If you manage or lead a healthcare practice, you don’t need to understand the technical details of APIs. You need to understand what they mean for your risk.
An API—Application Programming Interface—is a doorway between two systems. When your scheduling system books a telehealth appointment, it talks to your EHR through an API. When your billing system submits a claim, it talks to the clearinghouse through an API. When lab results come back, they arrive through an API.
Each of these doorways has a key. Sometimes it’s a literal key (called an API key). Sometimes it’s a username and password. Sometimes it’s a more sophisticated authentication token. But in every case, whoever holds that key can walk through the door.
If the key is stolen, copied, or never changed, anyone can walk through. And unlike a physical door, there’s no security camera watching who comes and goes. Most practices have no visibility into API activity whatsoever. The door opens and closes thousands of times a day—and nobody is watching.
The risk: API keys embedded directly in source code, configuration files, or deployment scripts. These credentials were set once during initial integration and have never been changed. They often exist in multiple environments—development, staging, and production—using the same key.
Why it matters: When a vendor is breached or a developer’s laptop is stolen, those hardcoded keys become the attacker’s master key. Because they’re embedded in code rather than managed in a secure vault, they can’t be rotated quickly—changing them means rewriting and redeploying the integration.
How common: In healthcare integrations, hardcoded credentials are the norm, not the exception. Most small practices lack the technical infrastructure for secure credential management.
The risk: An integration that only needs to read appointment times has full access to patient records. A billing connection that only needs to submit claims can also modify patient demographics. Permissions are set to “all access” because it was easier during setup.
Why it matters: If that credential is compromised, the attacker inherits every permission the integration has—not just what it actually uses. A scheduling API key with full EHR access turns a scheduling breach into a patient data breach.
How common: Most healthcare APIs are configured with the broadest possible scope. Developers choose “admin” access because scoping permissions requires documentation that doesn’t exist and testing that takes time nobody has.
The risk: Nobody watches API calls. There is no alerting on unusual volume, unusual timing, or unusual data access patterns. A bulk extraction of 50,000 patient records through an API looks identical to a normal nightly synchronization.
Why it matters: Without API monitoring, you have no way to detect a breach in progress. The scheduling vendor breach in our opening scenario went undetected for two weeks—not because the logs didn’t exist, but because nobody was looking at them.
How common: The vast majority of healthcare practices have zero visibility into API-level activity. They monitor user logins and maybe failed authentication attempts, but API traffic flows completely unwatched.
The risk: Your telehealth vendor uses a sub-processor for transcription. Your billing vendor uses a third-party clearinghouse. Your lab interface routes through an intermediary. Each of these hops creates another trust boundary—and their API security is now your problem.
Why it matters: Your BAA (Business Associate Agreement) is with your direct vendor. But the data flows through systems you’ve never evaluated, managed by teams you’ve never met, secured by controls you’ve never verified. If a sub-processor is breached, your patients’ data is exposed—and your practice is liable.
How common: Nearly every healthcare vendor relies on sub-processors. Most practices don’t know who these sub-processors are, let alone what security controls they maintain.
The risk: Staff-configured Zapier automations that copy patient appointment data to a Google Sheet. IFTTT workflows that send visit notifications to a personal Slack channel. A billing coordinator’s custom Python script that pulls reports from the EHR API using credentials stored in a plain text file on their desktop.
Why it matters: These integrations move PHI through channels that IT has never reviewed, approved, or even knows about. They bypass every security control, every audit log, and every BAA in your organization. And they’re created by well-meaning staff trying to do their jobs more efficiently.
How common: If your practice has more than five employees and uses cloud-based systems, you almost certainly have shadow integrations. Most practices discover them only after a breach.
The good news: you don’t need to rip out your integrations or rebuild your technology stack. You need to apply the same security discipline to your API connections that you already apply (or should apply) to your user accounts. Here are the five controls that matter most.
What to do: Every API key and service account credential in your environment should be rotated on a 90-day cycle at maximum. Treat API keys like passwords—because that’s exactly what they are.
How to start: Inventory every API key in your environment. Document where each key is stored, which systems it connects, and when it was last changed. Then establish a rotation schedule. For high-sensitivity integrations (EHR, billing), consider 30-day rotation.
The standard: NIST SP 800-63B provides guidance on credential lifecycle management. PR.PS requires that platform security controls include credential management for machine-to-machine authentication.
What to do: Audit every integration’s permission scope. If an integration only reads appointment data, it should only have read access to appointment data—not full access to the patient chart, not write access to demographics, not admin access to the system.
How to start: For each integration, document what data it actually needs and what access it actually has. Close the gap. Most EHR and telehealth platforms support granular API scoping—the settings just haven’t been configured.
The standard: ID.AM asset management requires understanding what each system can access. PR.PS platform security requires that access controls follow the principle of least privilege—for machines, not just humans.
What to do: Implement logging and alerting on API activity. At minimum, you should be alerted on: unusual call volume (10x normal), calls outside business hours, access to data sets that the integration doesn’t normally touch, and any failed authentication attempts.
How to start: Most platforms generate API logs by default—they’re just not being reviewed. Start by routing API logs to your existing SIEM or log management platform. If you don’t have one, even a basic log aggregation tool provides visibility you don’t have today.
The standard: NIST CSF 2.0 DE.CM (Continuous Monitoring) explicitly calls for monitoring of system-to-system communications. API traffic is system-to-system communication.
What to do: For every vendor integration, document the complete data flow—including sub-processors. Know where your data goes after it leaves your system. Require vendors to disclose their sub-processors and provide evidence of their security controls.
How to start: Send every integration vendor a simple questionnaire: Who are your sub-processors? What data do they access? What security certifications do they hold? What happens to our data if your contract with them ends? Add sub-processor disclosure requirements to your BAAs.
The standard: NIST CSF 2.0 GV.SC (Supply Chain Risk Management) and ID.AM (Asset Management) both require visibility into third-party data flows and dependency chains.
What to do: Conduct a shadow integration audit. Identify every unauthorized automation, script, or third-party connector that moves patient data outside of approved channels. Then either bring them under management or shut them down.
How to start: Ask your staff directly: “Are you using any tools, automations, or workarounds to move data between systems?” Frame it as an improvement initiative, not a disciplinary exercise. You need honesty, not silence. Then establish a simple approval process for new integrations.
The standard: ID.AM requires a complete inventory of data flows. Shadow integrations are, by definition, undocumented data flows that create unmanaged risk.
Use this template to document and assess every API integration in your practice. Each row represents a trust boundary that should be actively managed, monitored, and reviewed on a quarterly basis.
| Integration | Systems Connected | Data Sensitivity | Auth Method | Scope / Permissions | Monitoring | Vendor Assurance | Risk Score |
|---|---|---|---|---|---|---|---|
| EHR ↔ Telehealth | Epic/athena ↔ Doxy.me/Zoom | PHI (full chart) | API Key | Read/Write — full patient record | None | BAA only | HIGH |
| EHR ↔ Lab | EHR ↔ Quest/LabCorp | PHI (clinical) | HL7/FHIR Token | Read/Write — orders & results | Vendor-managed | BAA + SOC 2 | MEDIUM |
| Scheduling ↔ EHR | Calendly/vendor ↔ EHR | PII + insurance | API Key | Read/Write — patient roster | None | BAA only | HIGH |
| Billing ↔ Clearinghouse | EHR/PM ↔ Availity/Waystar | PHI + financial | SFTP + API Key | Read/Write — claims & eligibility | Basic logging | BAA + HITRUST | MEDIUM |
| eRx ↔ Pharmacy | EHR ↔ Surescripts | PHI (medications) | NCPDP/SCRIPT | Write — prescriptions | Vendor-managed | BAA + certified | MEDIUM |
| Portal ↔ EHR | Patient portal ↔ EHR | PHI (patient-facing) | OAuth 2.0 | Read — results, messages, billing | Audit log | BAA only | MEDIUM |
| Telehealth ↔ Scheduling | Telehealth ↔ Scheduling vendor | PII (contact info) | Webhook + API Key | Read/Write — appointments | None | BAA only | HIGH |
| Shadow / Zapier | Any ↔ Google Sheets/Slack | Unknown (likely PHI) | OAuth / personal | Unknown — unaudited | None | No BAA | CRITICAL |
Scoring guidance: Rate each integration as CRITICAL, HIGH, MEDIUM, or LOW based on: data sensitivity, authentication strength, permission scope, monitoring coverage, and vendor assurance level. Any integration with “None” for monitoring and broad permissions is HIGH or CRITICAL by default.
Can you produce a complete list of every API integration in your practice—including the authentication method and permission scope for each one?
Do you have a documented schedule for rotating API keys and service account credentials? Has it been followed?
Are you monitoring API call volumes and patterns for anomalies, or does API traffic flow completely unwatched?
Do you know every sub-processor that handles your patient data downstream of your primary vendors?
Have you conducted a shadow integration audit—asking staff directly about unauthorized automations or workarounds?
If a vendor notified you today that their systems were compromised, could you identify within one hour which API keys to revoke and which data may have been exposed?
If you answered “no” to more than two of these questions, your integration boundaries are a significant and unmanaged risk. The good news: these are solvable problems that don’t require tearing out your technology stack.
National Institute of Standards and Technology. (2024). Cybersecurity Framework 2.0. U.S. Department of Commerce. https://www.nist.gov/cyberframework
U.S. Department of Health and Human Services. (2024). Health Industry Cybersecurity Practices (HICP): Managing Threats and Protecting Patients. https://405d.hhs.gov/
U.S. Department of Health and Human Services, Office for Civil Rights. (2025). Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information. https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf
Venuto, J. (2026). The Compliance Trap: Why “HIPAA Compliant” Medical Groups Still Get Hacked. Hudson Valley CISO. https://www.hudsonvalleyciso.com
Venuto, J. (2026). Why HIPAA Compliance Isn’t Enough: A NIST CSF 2.0 Guide for Telehealth. Hudson Valley CISO. https://www.hudsonvalleyciso.com
Venuto, J. (2026). Protecting Hudson Valley Patients: Why Telehealth Providers Are Moving From “Checklist” to “Governance.” Hudson Valley CISO. https://www.hudsonvalleyciso.com
The breach won’t come through the front door. It will come through the API connection nobody is watching. Map your risk before an attacker does.
A comprehensive review of your practice’s API integrations: credential lifecycle analysis, permission scope audit, vendor dependency mapping, and actionable recommendations for closing your integration security gaps.
Hudson Valley CISO
A Division of Security Medic Consulting
Fractional CISO Services | Healthcare Security | Telehealth Compliance