Platform Security

Effective Date: April 14, 2026 · Platform: telehealth.yourmd.online

YourMD.online, LLC and United Medical Group are committed to protecting the security, privacy, and confidentiality of your health information. Our telehealth platform is built from the ground up with HIPAA and HITECH compliance as a core requirement, not an afterthought.

1. HIPAA & HITECH Compliance

YourMD Telehealth is designed to meet or exceed the requirements of the HIPAA Security Rule (45 CFR 164.302-318) and the HITECH Act. Our compliance program includes:

• Administrative Safeguards: Documented risk analysis, incident response plan, business continuity procedures, workforce security training, and assigned security responsibility
• Technical Safeguards: Access controls, audit controls, integrity controls, person/entity authentication, and transmission security
• Physical Safeguards: Managed through our HIPAA-compliant cloud infrastructure provider (Microsoft Azure) with BAA in place
• Regular Evaluation: Security controls are reviewed and updated on a continuous basis

2. Data Encryption

• In Transit: All data is encrypted using TLS 1.2+ (HTTPS) with HTTP Strict Transport Security (HSTS) enforced across the entire platform. This includes all web pages, API calls, file uploads, and messaging.
• At Rest — Infrastructure Layer: Protected health information (PHI) stored in our database and cloud storage is encrypted using AES-256 bit encryption provided by Microsoft Azure's platform encryption with customer-managed keys.
• At Rest — Application Layer (defense in depth): In addition to infrastructure encryption, YourMD applies a second independent layer of application-managed cryptography so that a compromise of the database or storage tier alone cannot expose patient data in plaintext. We use modern authenticated encryption (XChaCha20-Poly1305) via libsodium, with per-purpose key separation derived from a master key held exclusively in our cloud platform's secret store. The application layer uses only vetted primitives; legacy algorithms such as AES-ECB, MD5, and SHA-1 are prohibited throughout our code base.
• PHI Column Encryption: Sensitive clinical narrative fields (medical history, current medications, allergies, chief complaint, assessment, plan) are encrypted at the column level with additional authenticated data binding each record to its owning patient, so that a leaked ciphertext cannot be re-linked to a different record. Reads are transparent to providers and reviewers.
• File Vault for Patient Uploads: Patient-uploaded files — identity documents submitted during registration, insurance cards, progress photos, and medical records — are encrypted at the application layer before they reach storage, each with a purpose-separated sub-key and a per-user authenticated data binding. Access to decrypted images is mediated by a server-side streaming endpoint that audit-logs every view and refuses to render during administrator impersonation.
• Database Connections: All connections between our application servers and database use SSL/TLS encryption.
• Telehealth Sessions: Video and audio consultations are encrypted using industry-standard protocols. Session data is isolated with unique per-session encryption keys and does not persist on your device after the call ends.
• Secret Management: Application secrets including the master encryption key, proof-of-work signing key, authentication tokens, and third-party API credentials can be migrated to a dedicated secret store (Azure Key Vault) with managed-identity-authenticated access. The master encryption key is the root of trust for every application-layer cryptographic operation; rotation is an explicitly controlled maintenance event.

3. Identity Verification & Authentication

• Registration Review (NIST IAL2): All new accounts undergo identity verification. Patients upload government-issued ID (front and back) during registration. A licensed administrator manually reviews and approves each submission before access is granted — we do not rely on automated face-matching software for primary identity proofing.
• Single Authentication Path: The platform exposes exactly one production login flow. There are no test accounts, demo credentials, hardcoded passwords, or "shadow" login pages anywhere in the production code base. We audit for and remove any such paths on every release.
• Self-Registration Restricted to Patients: Public account creation is limited to patient and therapy-patient roles. Privileged roles (clinician, biller, administrator) are provisioned exclusively by an existing administrator through a sealed user-management tool that requires multi-factor authentication and writes an audit trail.
• Password Policy (NIST SP 800-63B-aligned): Passwords require a minimum of 12 characters with complexity requirements (uppercase, lowercase, numbers, special characters) and are checked against known-breached password lists. Passwords are hashed using bcrypt with a high cost factor — we never store plaintext passwords and never email or display them. Password reuse is prevented by comparing each new password against the last several hashes in a per-user history, and password reset invalidates every active session for that user (NIST SP 800-63B requirement). Periodic rotation is opt-in rather than mandatory, following NIST guidance that arbitrary rotation schedules reduce overall security.
• Multi-Factor Authentication (MFA): TOTP-based multi-factor authentication is available for all roles and is enforced by default for clinicians and administrators. Backup codes are provided for account recovery, and recovery flows themselves require MFA re-verification.
• Session Security: Sessions comply with NIST SP 800-63B guidelines, including session ID regeneration on every authentication step, automatic timeout after inactivity, session fingerprinting (subnet, user agent, browser characteristics), and secure cookie configuration (HttpOnly, Secure, SameSite=Strict). Concurrent session limits prevent credential sharing.
• Account Lockout & Rate Limiting: Accounts are automatically locked after multiple failed login attempts. Login endpoints carry stricter per-IP rate limits than ordinary API traffic to prevent credential-stuffing and brute force attacks. Every authentication handler passes through a unified security middleware layer that additionally performs bot detection and auto-blocks any network address exceeding the failure threshold.
• Anti-Bot CAPTCHA (six defensive layers): Login, registration, and password-reset forms are protected by a purpose-built CAPTCHA stack that combines (1) a hidden honeypot field, (2) form-submission timing analysis, (3) a cryptographically signed client-side proof-of-work challenge, (4) behavioral scoring across mouse, keyboard, focus, click, and scroll events, (5) a visible image fallback if any frictionless layer fails, and optionally (6) a third-party enterprise CAPTCHA. The proof-of-work challenges are signed with a secret key held in our cloud platform's secret store so the server can reject forged solutions.
• Administrator "View As" Controls: When an administrator needs to view the platform as another user for support, the action is gated by a dedicated tool that refuses to impersonate other administrators, refuses nested impersonation, regenerates the session identifier, and writes an audit-log entry attributed to the original administrator on both impersonation start and end.

4. Access Controls

• Role-Based Access Control (RBAC): Access to patient data follows the HIPAA "minimum necessary" principle. Six distinct roles (patient, therapy patient, provider, therapist, biller, administrator) each have specific permissions limiting data access to only what is needed for their function.
• Break-the-Glass Minimum-Necessary Gate: Access to sensitive patient records (minors, psychiatric records, patients outside a normal care relationship, medication histories, lab orders and results, billing staff accessing clinical data) requires the requesting user to document a justification reason before the record is released. Each justification is scoped to a single patient, valid for one hour within the current session, and written to the tamper-evident audit chain along with the reason, role, timestamp, and network address. Providers cannot browse the database — they can only see records for which they have either a treatment relationship or a documented break-the-glass reason.
• Segregation of Duties: Billing staff can access patient demographics and billing codes but have limited access to clinical notes. Providers cannot access financial transaction data. Administrative functions are separated from clinical functions.
• Concurrent Session Limits: Users are limited to a maximum number of concurrent sessions to prevent credential sharing.
• Controlled Substance Policy: Our platform does not prescribe controlled substances. The prescription system actively blocks and logs any attempt to prescribe medications on DEA controlled substance schedules.

5. Telehealth Session Security

• Session Isolation: Each telehealth consultation operates in a cryptographically isolated session with unique encryption keys generated for each call.
• Zero-Persistence: No protected health information is stored on your device during or after a telehealth session. All session data exists only in memory during the active call and is securely destroyed when the session ends.
• Signed Session Tokens: Access to telehealth sessions is controlled through cryptographically signed tokens that prevent unauthorized access or tampering.
• Real-Time Monitoring: Active telehealth sessions are monitored by our security operations team for anomalous activity.
• Encrypted Transcripts: If session notes or transcripts are saved, they are encrypted before storage and accessible only to authorized providers.

6. Monitoring, Audit & Incident Response

• Comprehensive Audit Trail: Every access to PHI is logged with user identity, action performed, timestamp, IP address, and user agent. Audit logs are retained for 7 years per HIPAA requirements. Audit log records are append-only — deleting a user account does not remove that user's historical audit entries.
• Tamper-Evident Audit Chain: Every audit record is additionally sealed into a cryptographic hash chain, where each row's authentication code is computed over the previous row's authentication code concatenated with the canonical serialization of the current row. The chain key is derived from a master secret stored exclusively in our cloud secret store, so an attacker who compromises the database alone cannot forge, reorder, or silently delete audit entries — any such tampering breaks the chain and is detectable by re-walking the log. A scheduled job verifies the full chain on an automated cadence and escalates any integrity failure to our security operations inbox.
• Daily Security Reviews: Our engineering team performs an automated and human-reviewed security scan of the entire production code base every business day. Findings are triaged the same day, patched within 24 hours for critical issues, and recorded in an internal evergreen security log. The scan results inform a running daily-change journal visible to platform administrators.
• Defense-in-Depth Patch Cadence: We do not wait for vulnerability disclosures to harden the platform. New defensive layers are added proactively, even where existing controls are believed to be sufficient, so a single failure cannot expose patient data.
• Security Operations Dashboard: An admin cybersecurity control center provides real-time visibility into active users, failed login attempts, security events, locked accounts, blocked addresses, and active telehealth sessions, with one-click incident response actions. A separate security-configuration panel surfaces the live status of every cryptographic component, captcha subsystem, password policy, and required secret so operators can detect misconfigurations immediately.
• Rate-Limited Security Alerting: A dedicated incident-notification pipeline delivers severity-tagged emails to our security operations inbox whenever the platform detects an integrity anomaly (broken audit chain, missing secret, database outage during a chain verification). Critical and warning alerts are rate-limited independently to prevent alert fatigue while guaranteeing escalation of real incidents.
• Automated Threat Detection: Rate limiting (configurable per endpoint), bot detection, SQL injection pattern blocking, command injection blocking, path-traversal blocking, and malicious file upload prevention are enforced on all requests at the application layer in addition to cloud-provider WAF rules.
• Network Address Management: Suspicious network addresses are automatically blocked after repeated failed authentication attempts. Administrators can manually block or unblock addresses with documented reasons and configurable durations.
• Cryptographic Self-Test: An administrator-only health-check endpoint exercises every cryptographic primitive end-to-end (key derivation, authenticated encryption, tamper detection, wrong-context rejection, file vault round-trip, PHI column round-trip, legacy plaintext fallback). This is the first diagnostic step any time a crypto-related anomaly surfaces, and it is safe to run on production because every operation works on ephemeral in-memory values.
• Incident Response: We maintain a documented incident response plan with procedures for identifying, containing, eradicating, and recovering from security incidents. Breach notification is provided within 60 days to affected individuals and to the U.S. Department of Health and Human Services as required by the HITECH Act, with sooner notification when warranted.

7. Infrastructure

• Cloud Provider: Microsoft Azure with HIPAA Business Associate Agreement (BAA) in place
• Region: United States (Central US)
• Database: Azure MySQL with SSL-enforced connections and automated daily backups
• HTTPS Enforcement: HTTP access is automatically redirected to HTTPS. HSTS headers ensure browsers always use encrypted connections.
• Security Headers: Content Security Policy (CSP), X-Frame-Options (clickjacking prevention), X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers are set on all responses.
• DDoS Protection: Azure's built-in DDoS protection is enabled for the platform.

8. Third-Party Services

We carefully select third-party partners who meet our security and compliance requirements:

• E-Prescribing: MDToolbox, a certified e-prescribing platform integrated with pharmacy networks
• Payment Processing: Stripe (PCI DSS Level 1 certified). YourMD never stores, processes, or has access to your full credit card number.
• Cloud Storage: YMD Drive provides HIPAA-compliant encrypted document storage with AES-256 encryption, audit logging, and provider sharing controls
• AI Services: AskUnitedMedicalAI and health tools operate under our AI Terms of Use with data handling governed by our Privacy Policy

9. Privacy, Cookies & Consent

• First-Party Cookies Only: YourMD Telehealth does not use third-party tracking cookies, advertising pixels, or cross-site analytics tags. Every cookie the platform sets is first-party, strictly-necessary or functional, and is documented in our Cookie Disclosure.
• Granular Consent Manager: A GDPR- and CCPA-compliant consent banner is presented to every visitor on first arrival. Users can accept all categories, reject all non-essential categories, or choose per category (strictly necessary, functional, analytics, marketing). The consent state is stored in a first-party cookie so that clearing cookies also clears consent, and the banner version is bumped whenever a new category is introduced so existing users are re-prompted.
• Persistent Cookie Preferences Link: Every page in the platform and on our marketing site exposes a "Cookie preferences" link so users can revisit and change their choices at any time.
• Minimum Necessary Processing: Per the HIPAA minimum-necessary standard, any disclosure of PHI is scoped to the least amount needed to accomplish the authorized purpose. Our access controls and break-the-glass gate enforce this automatically at the application layer.

10. Application Security

• Parameterized Queries: Every database query uses parameterized prepared statements. We do not assemble SQL by string concatenation anywhere in the production code base, eliminating SQL injection as a class of vulnerability.
• Cross-Site Scripting (XSS): All user-controlled output is HTML-encoded at the rendering layer. A strict per-page Content Security Policy header restricts script sources to same-origin and a small allowlist of trusted CDNs, blocking inline scripts unless they carry a per-request cryptographic nonce.
• Cross-Site Request Forgery (CSRF) — Three Defensive Layers:
  1. Session cookies use the SameSite=Strict attribute, so the browser does not send credentials on any cross-site navigation.
  2. HTML form submissions are gated by a per-session CSRF token validated on every state-changing request.
  3. Application-layer JSON APIs additionally enforce a same-origin guard that rejects any state-changing request whose Origin or Referer does not match the platform host. This protects critical actions (subscription changes, prescription writes, medical record updates, document uploads) even if the first two layers were ever bypassed.
• HTTP Header Hardening: Strict-Transport-Security with includeSubDomains, X-Frame-Options DENY (clickjacking prevention), X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, and Permissions-Policy restricting camera, microphone, and geolocation to first-party use only.
• HTTP Response Splitting / CRLF Injection: User-controlled values that flow into HTTP response headers (file download names, redirects) are sanitized to strip control characters before they reach the response, preventing header injection attacks.
• File Upload Security: Uploaded files are validated by extension, MIME type sniffed from file content (not just the client-supplied Content-Type), and file size limits. Executable files and active content types are blocked. Uploaded files are stored outside the executable web root with random-bytes filenames so an attacker cannot guess upload paths.
• Secret Management: All API keys, database credentials, JWT signing secrets, and third-party tokens are loaded from runtime environment variables managed by our cloud provider. We do not commit secrets to the source code repository, and any historical reference to a secret is rotated on discovery.
• Anti-Bot Protection: Honeypot fields, form submission timing analysis, behavioral pattern detection, and CAPTCHA on high-value endpoints protect against automated abuse and credential stuffing.
• Information Disclosure Prevention: Production responses never include stack traces, internal file paths, server software versions, or database error details. All exceptions are logged server-side and the client receives a generic error message.

11. Vulnerability Disclosure & Responsible Reporting

If you believe you have discovered a security vulnerability affecting YourMD Telehealth, please report it to us privately rather than disclosing it publicly. We will acknowledge your report within two business days and work with you toward a coordinated fix. You may report via:

• Email: support@yourmd.online (subject line: SECURITY)
• Encrypted communication: available on request

Researchers acting in good faith and within the scope below will not be subject to legal action by YourMD.online, LLC. We ask that you:

• Avoid privacy violations, degradation of user experience, disruption to production systems, and destruction of data during your research.
• Use only test accounts you control. Do not interact with patient data that does not belong to you.
• Give us a reasonable opportunity to remediate before public disclosure.

12. Your Rights & Responsibilities

Your Rights:

• Access and download your medical records at any time through your patient portal
• Request amendments to your health information
• Request an accounting of disclosures of your PHI
• File a privacy complaint with us or with the HHS Office for Civil Rights

Your Responsibilities:

• Choose a strong, unique password and do not share it with anyone
• Enable multi-factor authentication on your account
• Conduct telehealth sessions from a private location
• Keep your device and browser updated
• Report any suspicious activity to our support team immediately

13. Contact Us

If you have security concerns, discover a vulnerability, or need to report a security incident:

• Email: support@yourmd.online
• Phone: 914-996-8763
• Customer Support: www.yourmd.online/customer

For HIPAA complaints, you may also contact the U.S. Department of Health and Human Services Office for Civil Rights at hhs.gov/hipaa.

YourMD.online, LLC · United Medical Group
www.yourmd.online · telehealth.yourmd.online