Security for Telemedicine: protecting teleconsultations from interception and unauthorized access

Audio, video, and clinical data flowing in real time, exposed on the internet. We show the anatomy of unauthorized access to teleconsultation rooms via predictable links — and how Decripte discovers, contains, and shields against that risk with pentesting, a 24/7 SOC, end-to-end encryption, and compliance.

Direct answer

To protect a telemedicine platform, treat the teleconsultation room as a critical clinical asset: replace predictable links with single-use invitations that expire quickly, require strong authentication (MFA) from both physician and patient, enforce end-to-end encryption on audio and video transport (WebRTC with DTLS-SRTP), segregate session data from persisted clinical data, monitor room-entry attempts with a 24/7 SOC, and validate everything with pentesting focused on signaling, token generation, and WebRTC. Decripte covers these fronts with specialized Pentesting, a 24/7 SOC, Incident Response (containment within 1h), and compliance with the LGPD and the CFM resolutions on telemedicine.

24/7

SOC monitoring rooms and signaling

<=1h

Incident containment SLA

LGPD

Health data is sensitive personal data

CFM

Regulated telemedicine (Res. 2,314/2022)

In summary

  • Predictable room links (sequential IDs, short tokens, or no expiration) are the most underestimated vector in telemedicine: they let a third party enter a teleconsultation without ever attacking the infrastructure.
  • Clinical data transmitted in a teleconsultation is sensitive personal data under the LGPD; processing it requires an adequate legal basis, minimization, and technical security proportional to the risk.
  • Transport encryption (HTTPS) is not enough: WebRTC media needs DTLS-SRTP, and in architectures that route through media servers, you must explicitly decide where the session is decrypted and who has access to it.
  • Telemedicine pentesting is not just a web app: it covers the signaling channel, the generation and lifecycle of room tokens, the WebRTC flow, mobile apps, and the TURN/SFU server.
  • The combination that sustains the operation is Pentesting (discovers) + Edge Security (protects the perimeter) + 24/7 SOC (detects) + Incident Response (contains within 1h).
Saúde

Cibersegurança para Telemedicine

Audio, video, and clinical data flowing in real time, exposed on the internet. We show the anatomy of unauthorized access to teleconsultation rooms via predictable links — and how Decripte discovers, contains, and shields against that risk with pentesting, a 24/7 SOC, end-to-end encryption, and compliance.

Why telemedicine is a high-value, low-friction target

Telemedicine has shifted from an alternative channel to core care infrastructure. A single remote-consultation platform concentrates, in real time, three classes of extremely sensitive information: the audio and video of the consultation, identification data, and the clinical data discussed or recorded during the session. Unlike a traditional hospital system that lives behind firewalls and VPNs, the teleconsultation platform must be exposed on the public internet so that patient and physician can connect from anywhere, on any device. That exposure is the product's function — and it is exactly what creates the risk surface.

From an attacker's standpoint, telemedicine combines two attributes that rarely coexist: high information value and low access friction. The value is obvious — health data is monetizable through fraud, extortion, and sale on illicit markets, and it carries disproportionate reputational and legal weight. The low friction comes from engineering decisions made to make the product easy to use: short, shareable room links, entry without registration to reduce drop-off, and tokens with generous lifetimes so as not to frustrate the patient who clicks in late. Each of these choices, in isolation, seems reasonable. Together, they can turn a teleconsultation room into something anyone with the link can access.

The risk no one sees on the roadmap

The most likely attack against a teleconsultation platform is not a sophisticated zero-day exploit. It's someone entering a room because the identifier was guessable, the token never expired, or the system never verified that whoever entered was really the expected patient. This vector does not show up in an automated vulnerability scanner — it shows up in business-logic pentesting.

The result is that many telemedicine platforms pass clean infrastructure audits — TLS configured, security headers present, dependencies up to date — and still carry a critical confidentiality risk in the very mechanics of how rooms are created and accessed. It is exactly this kind of risk, invisible to tools and visible only to an analyst who thinks like an attacker, that Decripte was built to find before it becomes an incident.

How a link becomes an open door

Every teleconsultation takes place inside a virtual room, and every room needs an identifier. The critical security question is: how hard is it for someone who wasn't invited to discover or guess the identifier of a room that is happening right now? When the answer is easy, the platform has a confidentiality problem at its root, no matter how well everything else is configured.

The insecure patterns we find in the field follow a few archetypes. The first is the sequential or semi-sequential identifier: rooms numbered in order, or derived from the appointment ID, the CPF, the patient number, or a timestamp. If room 10482 exists, an attacker tries 10481, 10483, 10484 and figures out the pattern. The second is the short, low-entropy token: a six-character alphanumeric code may seem sufficient, but if there are thousands of simultaneous consultations, the effective search space shrinks and brute-force guessing becomes viable. The third is the token with no expiration or a long expiration: yesterday's consultation link still opens the room today, or the room stays open after the consultation ends. The fourth, and most serious, is the absence of identity verification at entry: the room trusts whoever has the link, without checking whether that device, that authenticated session, or that patient is the expected one.

The four flaws that open a room

  • Predictable identifier: rooms derived from a sequence, appointment, CPF, or timestamp allow enumeration.
  • Low-entropy token: short codes become guessable under a high volume of simultaneous consultations.
  • Token with no expiration or a room that doesn't close: yesterday's link still works; the room stays alive after the consultation.
  • Entry without identity verification: the room trusts whoever has the link, not the person the link should belong to.

Why this slips past traditional defenses

This vector is insidious because it violates no obvious technical rule. HTTPS is perfect. WebRTC negotiates DTLS-SRTP correctly. The application firewall sees nothing wrong, because access to the room is a legitimate request with a valid token — just a token that belonged to someone else. It's an authorization-logic problem, not a transport-configuration one. That's why the defense isn't a product you buy and switch on: it's a combination of correct token design, strong authentication at entry, aggressive expiration, and monitoring that detects the enumeration pattern (many failed entry attempts, or entries from improbable origins) in real time.

The principle Decripte applies

Having a room's link cannot be enough to enter it. The link invites; authentication authorizes. Every teleconsultation room must, at a minimum, require the participant to prove they are who should be there — via an authenticated session with MFA, a single-use code delivered through a separate channel, or prior validation in the scheduling flow.

Gestão de Ameaças · Grátis

Is telemedicine data already exposed or up for sale? Find out now — for free.

Sem cartão, sem compromisso. Descubra em minutos o que já vazou da sua empresa e qual é o seu risco real.

End-to-end encryption: what really protects audio and video

There is a common confusion between transport encryption and encryption of the call's media. When a patient accesses the platform over HTTPS, the web traffic is protected in transit — but that concerns the pages, the APIs, and the signaling, not necessarily the audio and video of the consultation. The real-time media flow uses WebRTC, and proper protection of that flow depends on DTLS-SRTP: keys are negotiated via DTLS and the media itself is encrypted with SRTP. Without this explicitly guaranteed, there are scenarios in which media packets could be captured and reconstructed.

The subtlest point appears in the media architecture. Point-to-point calls (between two participants) can keep the media genuinely encrypted end to end. But most platforms use a media server — an SFU (Selective Forwarding Unit) or MCU — to scale, record consultations, transcribe, or support multiple participants. In these architectures, the media is normally decrypted on the server to be forwarded. This is not necessarily wrong, but it is a decision that must be deliberate and protected: whoever has access to that server, in theory, has access to the consultation's content. The correct security question is not only whether there is encryption, but where the session is decrypted and who can touch it at that point.

Encryption checklist for teleconsultation

  • WebRTC with DTLS-SRTP confirmed and mandatory for the entire media flow, with no insecure fallback.
  • Explicit, documented decision on media architecture: P2P versus SFU/MCU, and where the media is decrypted.
  • Media server (SFU/MCU) and TURN server hardened, segregated, and with restricted, audited administrative access.
  • Modern TLS (no obsolete versions, no weak ciphers) across the entire web, API, and signaling surface.
  • Consultation recordings — where they exist — encrypted at rest, with an LGPD legal basis, defined retention, and audited access.
  • Keys and secrets out of the code, in a managed vault, with defined rotation.

Decripte validates each of these points in pentesting and helps structure the media architecture so that the confidentiality decision is deliberate and defensible, rather than a side effect of how the WebRTC library came configured by default.

The full surface: what a telemedicine pentest needs to cover

Pentesting a teleconsultation platform is broader than a conventional web application test. The real-time, multi-device, multi-protocol nature of telemedicine creates surfaces a generic scope cannot reach. A well-done telemedicine pentest traverses the entire chain that links the patient to the physician.

Scope of a telemedicine pentest

  • Generation and lifecycle of room tokens: entropy, predictability, expiration, revocation at the end of the consultation.
  • Entry authorization logic: does the room verify identity, or trust whoever has the link?
  • Signaling channel (WebSocket/HTTP): authentication, message injection, signaling session hijacking.
  • WebRTC flow: DTLS-SRTP negotiation, IP exposure via ICE/STUN, abuse of the TURN server as a relay.
  • Mobile apps (iOS/Android): local token storage, certificate pinning, data exposure in logs and cache.
  • Backend APIs: IDOR over records, scheduling, and recordings; access control between physician, patient, and administrator.
  • Authentication and session: MFA, password policy, session fixation and expiration, account recovery.
  • Phishing resistance: surfaces an attacker would impersonate to capture physicians' credentials.

The special case of the TURN server

The TURN server exists so the call works even when participants are behind NATs and restrictive firewalls — it relays the media. Misconfigured, it becomes two problems: it can leak participants' internal IP addresses via ICE candidates, and it can be abused by third parties as an open relay for arbitrary traffic, turning your infrastructure into a springboard for other attacks. It is a component that rarely enters the scope of generic audits and almost always has something to fix when it enters ours.

IDOR is the silent vector of clinical APIs

Insecure Direct Object Reference (IDOR) happens when the API hands over another patient's medical record, recording, or appointment simply because the ID was swapped in the request, without checking whether the requester is entitled to that resource. In healthcare, a single IDOR can expose the entire patient base. It's one of the first targets of our telemedicine API pentesting.

The strongest encryption offers no protection against a physician who types their password into a fake page. Health professionals are attractive targets: they have access to multiple medical records, tend to operate under time pressure, and don't always go through regular security training. An email that mimics the telemedicine platform, a false urgent-consultation notice, a cloned login page — any of these can deliver a physician's credential, and with it access to everything that professional can reach.

The mitigation has three layers, and all three matter. The first is technical: phishing-resistant MFA drastically reduces the value of a stolen credential, because the password alone is no longer enough. The second is monitoring: the 24/7 SOC detects the anomalous login — improbable time, incompatible geolocation, new device, atypical access pattern — and acts before the intruder moves around. The third is edge intelligence: monitoring the registration of domains resembling the platform's (typosquatting) and phishing pages that mimic the brand, taking them down before they are used against the professionals.

Defense in depth against phishing

MFA strips the value from the stolen password. The 24/7 SOC detects the anomalous use of the compromised credential. Edge intelligence takes down the fake domain before it fires. None of the three alone solves it; the three together make the phishing campaign expensive and noisy — exactly what drives the attacker away.

Decripte treats phishing against the clinical team as an integral part of the platform's security posture, not as a separate HR problem. The free Threat Management plan at decripte.com.br/intelligence-center already provides initial visibility into exposures and brand impersonation associated with the platform's domain.

Gestão de Ameaças · Grátis

What would an incident in telemedicine cost? See your real risk before it happens.

Sem cartão, sem compromisso. Descubra em minutos o que já vazou da sua empresa e qual é o seu risco real.

Compliance: LGPD, ANPD, and the CFM rules for telemedicine

Health data is, under the LGPD, sensitive personal data. This raises the bar across the entire processing cycle: the legal basis must be adequate to the purpose (protection of health by a professional, consent where applicable, or another basis provided by law), collection must be minimized to what is necessary, and the technical and administrative security measures must be proportional to the risk. A teleconsultation generates several types of data simultaneously — identification, clinical content, session metadata, any recordings — and each requires a deliberate decision on legal basis, purpose, and retention.

In the event of a security incident that may pose a relevant risk or harm to data subjects, the LGPD provides for notification to the ANPD and to the affected subjects within a reasonable timeframe. For a telemedicine platform, this means that the ability to detect, scope, and document an incident quickly is not just good security practice — it is a regulatory requirement with deadline consequences. A well-instrumented incident, with a clear timeline and a defined scope, is the difference between a controlled notification and a crisis.

Regulatory layers telemedicine must meet

  • LGPD: health data is sensitive personal data; adequate legal basis, minimization, security proportional to the risk.
  • ANPD: duty to notify incidents posing relevant risk to data subjects and the authority within a reasonable timeframe.
  • CFM (Resolution 2,314/2022): regulates the practice of telemedicine, including requirements for confidentiality, recordkeeping, and information security.
  • Medical confidentiality: the confidentiality of the physician-patient relationship is a professional and legal duty, reinforced in the digital environment.
  • ISO 27001 and SOC 2: frameworks that structure and demonstrate security governance to clients and institutional partners.

The practice of telemedicine in Brazil is regulated by the Federal Council of Medicine, with CFM Resolution No. 2,314/2022 as the current framework. It addresses, among other points, the duty of confidentiality and the security and integrity of information in the remote consultation. The technical compliance Decripte structures — encryption, access control, auditing, retention — is precisely what sustains the fulfillment of these duties. Security and compliance, in telemedicine, are two sides of the same work.

Compliance on paper is not compliance in practice

Having a privacy policy and a consent form does not mean the platform is secure. The ANPD assesses the adequacy of the actual technical measures. A room accessible via a predictable link is a security flaw that translates, legally, into insecure processing of sensitive data — with the platform as the responsible controller.

How Decripte structures the platform's layered defense

No single layer protects a teleconsultation platform. Effective defense is in depth: each layer assumes the previous one can fail and limits the damage. Decripte organizes this defense around the real flow of a consultation — from the moment the patient clicks the link to the closing and safekeeping of the data.

The layers that sustain a secure teleconsultation

  • Identity: MFA for physicians and strong patient verification before entering the room.
  • Room: high-entropy, single-use tokens with short expiration and automatic revocation at the end of the consultation.
  • Media: WebRTC with mandatory DTLS-SRTP and a deliberate decision on where the media is decrypted.
  • Edge: WAF and DDoS protection shielding signaling, APIs, and public endpoints; bot and enumeration mitigation.
  • Data: segregation between session data and medical records, encryption at rest, retention, and access auditing.
  • Detection: 24/7 SOC correlating entry attempts, anomalous logins, and enumeration patterns.
  • Response: Incident Response plan with containment within 1 hour and support for regulatory notification.
  • Validation: recurring pentesting covering tokens, signaling, WebRTC, APIs, and mobile apps.

The thread that ties it all together is telemetry. There's no point in each layer existing if no one observes the whole in real time. Decripte's 24/7 SOC consumes the signals from each layer — entry failures, improbable logins, signaling traffic spikes, TURN abuse — and correlates them to distinguish normal noise from an attack in progress. It is this integrated view that makes it possible to contain an incident within an hour, before a compromised room becomes a database breach.

Anonymized real-world example: unauthorized access to rooms via predictable links

Real, de-identified example

Anonymized real-world example (client not identified). A mid-sized telemedicine platform ran hundreds of teleconsultations a day. Rooms were created with identifiers derived from the sequential appointment number, and the access link remained valid for 24 hours with no identity verification at entry — having the link was enough to get in. The product team considered this a convenience: the patient who missed their slot could still get in. Transport encryption was correct and previous infrastructure audits had passed without flagging the problem, because the defect was in the authorization logic, not the technical configuration.

  1. Discovery (Pentest)

    During a contracted pentest, Decripte mapped that the room identifiers were predictable from the appointment number and that entry did not validate identity. In a controlled and authorized environment, the team demonstrated that it was possible to enumerate active rooms and enter a test teleconsultation without having been invited — without touching the infrastructure, simply by exploiting the logic of the link. The finding was classified as a critical confidentiality issue.

  2. Detection and alerting (24/7 SOC)

    With the hypothesis confirmed, the SOC instrumented the entry telemetry and immediately identified, in real traffic, patterns consistent with enumeration: multiple entry attempts on sequential rooms from atypical origins. What had been invisible now generated alerts in real time, showing that the vector was not merely theoretical.

  3. Containment (<=1h)

    With the Incident Response plan activated, containment occurred within the SLA of up to one hour: aggressive shortening of token validity, invalidation of active unverified links, blocking of the origins running the enumeration, and activation of edge mitigation to stop the scanning of identifiers.

  4. Eradication

    The root cause was fixed: the sequential identifiers were replaced with high-entropy, single-use tokens with short expiration, automatically revoked at the end of the consultation. Entry now requires identity verification — an authenticated patient session and mandatory MFA for physicians. The room stopped trusting whoever has the link and now authorizes whoever proves to be the expected participant.

  5. Recovery

    The platform returned to full operation with the new room mechanics. The media flow was revalidated to ensure mandatory DTLS-SRTP, and the media-server architecture was reviewed to make the point where the session is decrypted explicit and restricted. Recordings began to be encrypted at rest, with audited retention and access.

  6. Continuous monitoring

    The 24/7 SOC took on permanent surveillance: detection of enumeration attempts, anomalous physician logins, and TURN server abuse, with correlation across layers. Edge intelligence began monitoring domains and pages mimicking the brand to anticipate phishing against the clinical team.

  7. Lessons learned

    The incident demonstrated that the greatest threat to confidentiality was not in the encryption, but in the room's access logic — exactly the kind of flaw an automated scanner cannot see and that only a pentest with an attacker's mindset reveals. Product convenience and access security must be negotiated deliberately, with recurring pentesting as a permanent guard.

Outcome with Decripte

In a single cycle, Decripte turned a critical, silent confidentiality risk into a defensible posture: predictable links replaced with unguessable single-use tokens, MFA for physicians, identity verification at entry, media confirmedly encrypted, and a 24/7 SOC watching the abuse pattern. The platform gained not only the fix, but the ability to detect and contain the next incident within an hour — and the documentation needed to sustain compliance with the LGPD and the CFM resolutions. Being an anonymized real-world example, it summarizes the method Decripte applies, adapted to each real platform.

Resposta a Incidentes · 24/7

Don’t wait for the incident. Start hardening telemedicine today.

Comece pelo diagnóstico gratuito agora e veja em minutos o que já vazou. SOC 24x7 e contenção em até 1h nos planos pagos.

How Decripte responds to a telemedicine incident

When a teleconsultation platform suffers a confidentiality incident — unauthorized room access, suspected interception, or compromise of physician credentials — every minute weighs in clinical, legal, and regulatory risk. Decripte follows a structured sequence, with containment within one hour.

  1. Immediate activation and triage: the Incident Response team takes over the case, classifies severity, and scopes the likely impact (how many rooms, which data, which subjects potentially affected).
  2. Containment within 1 hour: invalidation of suspicious active tokens and links, blocking of malicious origins, shortening of session validity, and activation of edge mitigation to stop enumeration and abuse.
  3. Forensic preservation: collection and preservation of entry, signaling, and authentication logs to reconstruct the incident timeline and support the investigation without destroying evidence.
  4. Root-cause eradication: fixing the defect that allowed access — predictable tokens, absence of identity verification, loose expiration, or a compromised credential — and not just the symptoms.
  5. Secure recovery: return to operation with the room mechanics fixed, MFA reinforced, media revalidated, and monitoring intensified during the period of highest post-incident risk.
  6. Support for regulatory notification: assistance in assessing risk to data subjects and in the documentation for eventual notification to the ANPD and to patients, in accordance with the LGPD, within the appropriate timeframe.
  7. Reinforced post-incident monitoring: the 24/7 SOC raises the sensitivity of alerts on the exploited vector and correlated patterns to detect recurrence attempts.
  8. Report and lessons learned: delivery of an executive and technical report with timeline, root cause, actions taken, and recommendations to close the risk window permanently.

How Decripte structures the security of a telemedicine platform

Responding to incidents is necessary, but the goal is for them not to happen. Decripte structures telemedicine security in mutually reinforcing pillars, from the code to continuous monitoring.

Continuous offensive validation (Pentesting)

Pentesting specialized in telemedicine covers the generation and lifecycle of room tokens, the entry authorization logic, the signaling channel, the WebRTC flow, the TURN server, the APIs, and the mobile apps. We find the logic flaw the scanner can't see, before the attacker finds it.

Strong access and shielded rooms

High-entropy, single-use tokens with short expiration, revoked at the end of the consultation; MFA for physicians and patient identity verification at entry. The room authorizes whoever proves to be the participant, not whoever merely has the link.

Encryption and media architecture

WebRTC with mandatory DTLS-SRTP, an explicit and protected decision on where the media is decrypted in SFU/MCU architectures, TURN hardening, and encryption at rest of recordings with defined retention and auditing.

Edge Security

WAF and DDoS protection over signaling, APIs, and public endpoints, with mitigation of bots and room-identifier enumeration, keeping the platform available and filtering malicious traffic before it reaches the application.

Detection and response (24/7 SOC)

Uninterrupted monitoring correlating entry attempts, anomalous physician logins, signaling spikes, and TURN abuse, with an Incident Response plan able to contain within one hour.

Compliance by design

Alignment with the LGPD for sensitive health data, support for the duty to notify the ANPD, and alignment with the CFM resolutions on telemedicine, structured with frameworks such as ISO 27001 and SOC 2 to demonstrate governance to institutional partners.

Recommended plans for Telemedicine

Frequently asked questions

Can teleconsultation links be intercepted or guessed by third parties?

Yes, when the room identifier is predictable (sequential, derived from the appointment or the CPF), the token is short or doesn't expire, and entry doesn't verify identity. In these cases, someone can enumerate rooms and enter a consultation without having been invited. The fix is to use high-entropy, single-use tokens with short expiration and to require authentication at entry. Decripte identifies exactly this risk in pentesting.

Does HTTPS encryption already protect the consultation's audio and video?

Not entirely. HTTPS protects the pages, APIs, and signaling. The audio and video travel over WebRTC and need DTLS-SRTP to be encrypted. In addition, if the platform uses a media server (SFU/MCU) to record or scale, you must deliberately decide where the media is decrypted and who has access to that point.

Does telemedicine have to comply with the LGPD even though it's a healthcare area?

It does, and with greater rigor. Health data is sensitive personal data under the LGPD, which requires an adequate legal basis, minimization of collection, security proportional to the risk, and, in the event of a relevant incident, notification to the ANPD and to the data subjects. The practice is also regulated by the CFM, with Resolution 2,314/2022 as the current framework.

How do you protect physicians from phishing that steals access to the platform?

With three layers: phishing-resistant MFA, which strips the value from the stolen password; a 24/7 SOC, which detects the anomalous login of the compromised credential; and edge intelligence, which monitors and takes down fake domains and pages mimicking the brand before they are used against the clinical team.

What does a telemedicine pentest assess beyond the web application?

It covers the generation and lifecycle of room tokens, the entry authorization logic, the signaling channel, the WebRTC flow, the TURN server (which can leak IPs or be abused as a relay), the mobile apps (token storage, pinning), and the backend APIs, where flaws such as IDOR can expose entire medical records.

How long does Decripte take to contain an incident on a teleconsultation platform?

Decripte's Incident Response works with a containment SLA of up to one hour. In practice, this means invalidating suspicious tokens and links, blocking malicious origins, and activating edge mitigation quickly, while preserving forensic evidence for the investigation and supporting regulatory notification.

Can I assess my platform's risk before hiring?

Yes. Decripte's free Threat Management plan, at decripte.com.br/intelligence-center, gives an initial view of the exposures and brand impersonation associated with your domain. For a full pentest and security structuring, you can sign up at decripte.io/start or talk to the team at decripte.io/contato.

Do teleconsultation recordings require special security care?

Yes. Recordings concentrate sensitive clinical content and require a specific legal basis under the LGPD, encryption at rest, a defined retention policy, restricted access control, and auditing of who accesses them. Storing recordings without these measures greatly amplifies the impact of a potential breach.

Sector terms

WebRTC / DTLS-SRTP
WebRTC is the technology that enables real-time audio and video directly in the browser. DTLS-SRTP is the mechanism that negotiates keys (DTLS) and encrypts the media (SRTP), ensuring the teleconsultation content travels protected, not in the clear.
TURN server
A server that relays the media when participants are behind NATs or restrictive firewalls, allowing the call to work. Misconfigured, it can leak internal IP addresses or be abused by third parties as an open relay for arbitrary traffic.
SFU / MCU
Media servers that receive and forward the audio and video streams to scale calls, record, or support multiple participants. In these architectures the media is usually decrypted on the server, which requires a deliberate decision about who has access to that point.
IDOR (Insecure Direct Object Reference)
A flaw in which the application hands over another user's resource — medical record, recording, appointment — simply because the identifier was swapped in the request, without verifying authorization. In healthcare, a single IDOR can expose the entire patient base.
Sensitive personal data (LGPD)
An LGPD category that includes health data. It receives reinforced protection: a specific legal basis, minimization of collection, and security proportional to the risk. Processing it insecurely constitutes a violation, with liability falling on the platform's controller.
CFM Resolution 2,314/2022
The current Federal Council of Medicine framework that regulates the practice of telemedicine in Brazil, addressing, among other points, the duty of confidentiality and the security and integrity of information in the remote consultation.

Decripte protects and responds to incidents in telemedicine.

Pentest, 24x7 SOC, incident response with a 1-hour containment SLA and compliance — without building an internal team. Or start free by seeing what has already leaked from your company.