eAssist Data Breach: What Dental Practices Need to Know

A ransomware group put a dental billing vendor on its leak site on September 6. Two days later the vendor told its customers it was investigating, and the group’s own description of what it says it took has been circulating among dental offices ever since.

On September 6, 2026, a ransomware group called DireWolf listed eAssist Dental Solutions as a victim on its dark web leak site. eAssist is one of the largest outsourced dental billing companies in the country, and it is majority owned by Henry Schein. On September 8 eAssist notified customers that it is investigating a potential information security incident and has engaged outside experts, which the Georgia Dental Association published the next day. At that point eAssist had not confirmed that customer or patient information was accessed or compromised, and no eAssist entry turns up in a search of the federal breach portal as of September 11, 2026. Federal reporting deadlines run from a breach being discovered rather than from a leak site post, so an absence this early tells you little either way.

Updated October 12, 2026: eAssist’s more recent customer communications acknowledge that data was exfiltrated from an eAssist system, and we now recommend that practices using eAssist evaluate an alternative billing provider. The October update below explains why. A September 30 update added eAssist’s follow-up notice to former customers and three federal lawsuits filed in Utah.

That leaves dental practices and DSOs in an awkward spot. The claim comes from a criminal group with an obvious incentive to exaggerate, the vendor has acknowledged that data was taken but says it has not established whose, and the pages ranking for this story are mostly law firms recruiting plaintiffs and threat feeds republishing the listing. None of them tell an operator what to do.

The short answer: eAssist now acknowledges that data was exfiltrated from an eAssist system, but says its investigation has not established which customers or patients may have been affected. A ransomware group named eAssist on its leak site on September 6, 2026, and on September 8 eAssist notified customers that an investigation is underway with outside experts engaged. No independent source has verified what the attacker says it took. If your practice sends data to eAssist, the useful response is not to wait for the investigation to finish but to inventory and tighten that vendor’s access to your systems this week, which is also what eAssist has told its own customers to do. A later eAssist notice to former customers recommends the same kind of password changes, so if your office once used eAssist and still has any active password assigned to or shared with it, or any eAssist user account still active, that work applies to you too. Because practice-specific answers still have not come, we now also recommend evaluating an alternative billing provider.

October update: eAssist acknowledges data was exfiltrated

More than a month after eAssist notified customers of a security investigation, dental practices are still waiting for the information they need to assess their exposure.

eAssist’s more recent customer communications, which have been shared with us, include an important acknowledgment: “What we do know is that data was exfiltrated from an eAssist system.” Exfiltration means data was taken out of that system. The same communications say the investigation has not established which customers or patients may have been affected. Meanwhile, eAssist is telling customers that consultant access to practice environments can continue.

That acknowledgment does not confirm the attacker’s claimed inventory or show that any particular practice’s patient information was involved. But an unresolved practice-specific determination is not an assurance that a practice was unaffected. Practices are being asked to keep trusting a vendor while the basic questions about the incident remain unanswered.

What the CTO letter and the LevelBlue memo actually say

In a letter from its CTO, eAssist says all of its Success Consultants, the billing staff who work inside client systems, have mandatory endpoint detection and response software on their devices. A detected threat leads to the device being quarantined and the consultant’s access to the offices they serve being suspended until the issue is resolved. Those are relevant protections. The letter does not explain the initial entry point, identify the information taken, or provide a practice-specific exposure assessment, and it does not say when those protections became universal.

eAssist has also provided a memorandum from the security firm LevelBlue, dated September 11, 2026. Its wording matters. The memo says eAssist conveyed to LevelBlue that a set of containment measures had been completed. That reports measures eAssist communicated. It does not state that LevelBlue independently validated each of them.

The memo also says no further suspicious activity related to the incident had been identified since September 9. In a document dated September 11, that covers a short period, and the memo is now more than a month old. The later customer message repeats the September 9 reference, but the memo itself provides no updated forensic assessment. Read it as a limited status update on an open investigation, not a security certification or a clearance to restore access.

Containment does not answer the exposure question

Two separate questions matter to a dental practice. Has the activity been contained? And what information or credentials were already taken, and what does that mean for your practice? Progress on the first does not settle the second. Finding no new suspicious activity does not recover data that already left, and a statement that operations are continuing normally describes service availability, not whether you can accept the remaining risk.

Forensic investigations take time, and a responsible vendor should avoid presenting preliminary assumptions as established facts. An unfinished investigation still allows meaningful communication: what is known, what remains unknown, what protective actions apply to you, and when the next update will come. Where an answer cannot yet be provided, the vendor should explain the limitation. The communications we reviewed leave customers without a practice-specific determination, a target date for that determination, or a defined update schedule.

In our reading, the wording does more to limit eAssist’s commitments than to help customers make informed decisions. We cannot know eAssist’s internal priorities. We can evaluate whether its communications meet the needs of the practices being asked to maintain its access, and at this stage we do not believe they do.

Our recommendation: evaluate an alternative billing provider

Given eAssist’s acknowledgment of data exfiltration and the continuing lack of actionable, practice-specific information, we recommend that practices using eAssist begin evaluating alternative billing arrangements. Work with your IT and HIPAA advisors to evaluate and restrict the access eAssist has today while you do, and prepare an orderly transition in case the answers that come back leave you with more risk than you are willing to carry.

That transition should protect billing continuity as well as information security. Coordinate outstanding claims, accounts receivable, data transfer and access removal, and apply the same scrutiny to a replacement provider’s security controls, consultant devices, access practices and incident communication commitments. Changing providers does not resolve any exposure that may already have occurred. In the meantime:

• Request written, practice-specific answers. Ask whether your data or credentials were stored on the affected system, whether your involvement has been ruled out, and what evidence supports continued access.
• Request a current assessment. Ask for updated findings and the scope of any independent validation, rather than relying solely on the September 11 memo.
• Involve your HIPAA advisor and, where appropriate, counsel and your cyber insurer, rather than relying exclusively on the vendor’s assurances. Keep every notice, attachment, question and response as part of your incident documentation.

Where HIPAA breach notification requirements apply, a business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery. That is an outside limit, not an automatic waiting period. The information we reviewed does not establish the applicable discovery date or whether a notification deadline has been missed.

What is actually known about the eAssist breach claim

Strip out the speculation and the confirmed facts fit in a short list.

DireWolf published a listing naming eAssist Dental Solutions and its domain, dentalbilling.com, on September 6, 2026. Threat intelligence trackers including Ransomware.live, RedPacket Security and BrinzTech indexed the posting. What those trackers establish is that the listing exists, not that an attack occurred. Every figure we have seen in circulation about what was taken, including every number below, traces back to that single attacker-authored page.

On September 8, eAssist notified its customers that it is investigating a potential information security incident and has engaged outside experts to assist with the investigation and response. The Georgia Dental Association published the substance of that notification on September 9. In it, eAssist says it has not confirmed that customer or patient information was accessed or compromised, that no specific records, credentials or patient data types have been verified as exposed, and that it will notify and provide guidance to affected parties as required based on what the investigation finds.

That is a meaningful change from the first days of this story, and it is worth reading precisely. Confirming an investigation is not the same as confirming a breach. What eAssist has acknowledged is the incident, not the attacker’s inventory. Its later communications go further, as covered in the October update above. That leaves three separate questions: whether data left an eAssist system (eAssist says it did), whether a particular practice’s information was involved (not yet established), and whether a reportable HIPAA breach occurred for your practice (an assessment for your HIPAA advisor, not one to leave to the vendor).

What still has not happened matters just as much. As of October 12, we have found no public statement from Henry Schein. And no independent party has verified the data the group says it holds.

Separately, three lawsuits naming eAssist were filed in federal court in Utah between September 14 and 24, 2026. The public docket entries do not describe what the complaints allege. On September 25, a filing to consolidate the cases was entered in the first of them. Our snapshot of dental data breach lawsuits shows how earlier cases against dental companies, including Henry Schein’s own, have settled.

None of that means the attacker’s inventory is false. It means the inventory is unverified, and those are different things.

eAssist breach timeline: what has happened so far

September 6, 2026. DireWolf published its eAssist listing, which Ransomware.live recorded at 16:55 UTC, together with the group’s own inventory of what it says it holds. Every figure we have seen in circulation comes from that one posting.

September 8, 2026. eAssist notified its customers that it is investigating a potential information security incident, engaged outside experts, and advised customers to change system passwords and remove old or inactive user accounts. At that point it had not confirmed that customer or patient information was accessed.

Through September. Threat trackers indexed the listing within hours and plaintiff firms opened investigations, while the claim spread through dental groups on LinkedIn and Facebook, in one case with a count of affected offices that appears nowhere in the posting. Henry Schein has not commented publicly, and no independent party has verified the attacker’s data.

Late September 2026. eAssist sent a follow-up security notice to former customers. In the copy published on September 28 by Dr. John Flucke, a dentist whose practice previously used eAssist, the company says it has determined that the data potentially involved may have included usernames and passwords used by eAssist team members to access customer systems. The notice presents its recommendations as precautionary, and at that point eAssist had not publicly confirmed that customer or patient information was accessed.

Since then. eAssist’s more recent customer communications, as shared with us, acknowledge that data was exfiltrated from an eAssist system, while saying the investigation has not established which customers or patients may have been affected. They point to a CTO letter on consultant endpoint protection and a LevelBlue memorandum dated September 11, and tell customers that consultant access to practice environments can continue.

What comes next is the outcome of that investigation. If eAssist was acting as your business associate, HIPAA requires it to notify you of a breach without unreasonable delay and no later than 60 days after discovery, and your agreement may set a shorter deadline. The formal clock can still run well past the news cycle, so plan for that gap rather than a quick resolution.

The numbers going around are the attacker’s numbers

You may have seen specific figures attached to this story: around 26 GB of data, 213 database tables, roughly 12.8 million database rows. Every one of those came from the attacker’s own posting, which lays out a database inventory in considerable detail.

Treat them accordingly. A leak site listing is an extortion tool, written to pressure a victim and advertise to buyers. Both goals reward inflation, and there is no independent confirmation of any of it.

One detail is worth knowing about where those numbers come from. The structured field where a data volume would normally appear on a tracker record is empty for this listing, which is why the trackers indexing it show no data size. The figures being repeated were read out of the body of the posting instead, where the group published its own overview and inventory of what it says it holds. The only source for the scale of this alleged theft is the party with the most to gain from making it sound large.

None of it changes what you should do. We tell the groups we work with to treat attacker figures as an unverified claim rather than a measurement, and to act on their own exposure instead, because your own data flows and vendor access are facts you can start documenting today from your own records.

What the DireWolf listing says was taken from eAssist

The posting is organized as a database inventory, table by table, with row counts, and a snapshot of the leak site page is publicly mirrored for anyone who wants to read the original without visiting the dark web. Grouped into the categories a practice would care about, it reads like this. Every number is the attacker’s claim, a row is a database record rather than a person or a practice, and where a category spans several tables the row shows the one table a practice would care about.

What the listing says it holds	Rows claimed	Why it matters to a practice
Insurance portal logins	13,119	Login records for the carrier portals your claims flow through
Dental office records	10,343	Includes per-office practice software and remote access passwords, software serial numbers and network names
Software, device, cloud and access credentials	8,955	File transfer, cloud storage and local sync accounts that connect eAssist to client systems
EOB, claims and billing records	530,213	Insured and patient names, dates of birth, payer, procedure narratives and payment dates from 2001 to 2026
Provider onboarding records	22,871	Dentist names and email addresses collected when an office signed up
Accounting, AR, deposit and financial records	5,543,186	Per-office invoices, deposits, AR balances and scorecards

Those six rows come to roughly 6.1 million of the 12.8 million. Most of the rest is internal to eAssist: about 3.3 million rows of payroll and commission detail, 1.1 million rows of employee accounts and time records, 618,000 survey records, 535,000 archived emails and reports, 493,000 applicant and hiring records, 153,000 sales lead records covering prospect offices and their staff, and smaller sets of contracts, onboarding files and support tickets. The 12.8 million total is the attacker’s own figure.

The credential claims are the part that reaches your practice

The posting itself labels the credential vaults its top risk, and that is the right place to start regardless of who is saying it. The posting says the office master holds each office’s practice software password and remote access password, describes the portal logins as per-office logins for insurance carrier portals, and adds that the stored passwords sit behind an encryption scheme the group says it can reverse, with a handful it says are readable outright. A claim that it can decrypt them is not evidence that it has.

In plain terms: if the claim is accurate, a working login to your practice management software, your remote access tool and your payer portals may be in a criminal group’s hands. That is why credential rotation and multi-factor authentication lead the action list below, and why both are worth doing before the investigation says whether your practice was involved.

eAssist’s own follow-up makes a separate and narrower point. Its notice to former customers says the data potentially involved may have included usernames and passwords its team members used to access customer systems. That does not confirm the attacker’s claim, and it does not say any credential was taken. As a precaution, eAssist strongly recommends changing every active password assigned to or shared with eAssist, including practice management systems, clearinghouses, claim software, payer portals, desktop logins, email accounts and office-managed VPNs. It also recommends removing any old or inactive eAssist user accounts still active in those systems, and deleting any shared document or spreadsheet the office created and gave eAssist that contains credentials or other sensitive information.

The patient and claims data it describes

About 530,000 rows of EOB and claim records, which the posting says carry insured and patient names, dates of birth, the payer, procedure narratives and payment dates, plus roughly 258,000 rows of patient concern tickets, daily patient financial reports and work lists. This is the category a HIPAA breach analysis would turn on if the exposure is confirmed, and it is also the category most likely to reach a patient as a convincing phone call. One detail worth noting: the payment dates in those records run back to 2001, so the exposure the posting describes is not limited to recent claims.

What the listing says about eAssist’s own workforce

Payroll, commissions, employee accounts, applicant files with background check flags and banking details, and the email archives are serious for eAssist’s own workforce and do not reach into your systems directly, though a compromised vendor mailbox or employee identity can still be used to impersonate the vendor to its clients. One direct exception: the 153,000 rows of sales leads cover prospect offices and their staff, so an office that only ever took a sales call could still see targeted phishing that knows its name.

Who eAssist is, and why this vendor matters

eAssist sells outsourced dental billing and revenue cycle management: insurance claims, patient billing, insurance verification, credentialing. Henry Schein acquired a 70% ownership position in June 2021, and eAssist’s own website says it serves more than 3,000 dental practices.

A remote billing service cannot do its job without reaching into your systems. That typically means access to your practice management software, a route into your claims and patient ledgers, and credentials for the payer portals your claims flow through. The whole value of the service is that someone outside your building can work inside your systems.

That is why this incident deserves your attention before the investigation finishes. The concern is not one company’s servers. It is that a billing vendor is, by design, holding keys to a lot of practices at once.

As for who DireWolf is, the short version is the part that matters to you. The group surfaced in May 2025 and runs a double extortion model, encrypting systems to disrupt operations and stealing data to threaten publication. Security firm Proven Data counted 127 claimed victims as of September 7, 2026, with healthcare the largest slice at 17%. That concentration is the signal worth keeping: healthcare data stays valuable for decades, downtime is expensive, and the industry increasingly routes its data through vendors who hold many organizations’ records in one place. For dentistry specifically, our count of dental businesses named on ransomware leak sites checks which of the businesses named between October 2025 and September 2026 had filed a public breach report.

What should a dental practice that uses eAssist do now?

Here is the reframe that makes this manageable. You do not need the investigation to finish before you act. You are deciding whether your exposure to that vendor is acceptable, and most of what that takes, knowing what you send them and how they get in, you can work out today from your own records.

Every step below is worth doing regardless of how this particular claim resolves. That is the test we apply to any incident whose scope is still unresolved. Work that only pays off if the claim is true is a bet. Work that pays off either way was already overdue.

If your practice used eAssist in the past, check for active passwords assigned to or shared with it and eAssist user accounts that are still active. Follow the relevant access and password steps below even if you no longer use the service.

1. Write down what you actually send them

Most practices cannot answer this quickly, which is itself the finding. List what data leaves your practice for the vendor, what comes back, and how. Claims files, patient demographics, insurance details, ledgers, imaging attachments. Not what the contract says. What actually moves.

2. Find every way they can get in

Inventory the live connections: remote access into your practice management software, any interface between their platform and your systems, file transfer accounts, shared drives. Vendor access tends to accumulate quietly. Someone set it up during onboarding years ago and nobody has looked since.

3. Rotate the credentials attached to those pathways

Change the passwords tied to vendor access, especially any shared account. An administered password manager keeps that shared-credential inventory in one place, so you can see which accounts need changing. Coordinate it with the vendor and your own team first, because rotating a credential that an active integration depends on can interrupt claims work. Done in order it is one of the cheapest ways to close a path between a vendor compromise and your practice.

While you are in there, turn on multi-factor authentication for every vendor-facing account that can support it, rotate file transfer keys and integration tokens along with the passwords, sign out any active sessions and remembered devices, and confirm the vendor contact you hand new access to through a phone number you already had. Look hardest at remote support and remote desktop tools. The attacker’s inventory specifically names remote access passwords for individual offices, and that is the category that turns a vendor breach into a practice breach.

This is also where a lot of dental groups discover an uncomfortable arrangement they have been living with for years. Outsourced billing frequently runs on shared payer portal logins, one account and one password used by whoever is working the claim that day. Rotating that password is the small fix. The payer portal problem underneath it is the larger one, and several carriers will issue individual logins to your team if you ask.

4. Read your access logs

Look at vendor account activity for the last several months. Logins at odd hours, from unfamiliar locations, or pulling far more records than a billing task requires. You are looking for the shape of bulk data access, not a single suspicious login.

5. Cut access down to what the work requires

A biller working claims does not need administrative rights, every patient record in your database, or access that outlives the engagement. Most vendor accounts are over-permissioned because it was faster to grant broad access than to scope it properly.

6. Pull the agreement out of the drawer

Find the signed business associate agreement and read what it obligates the vendor to do when they have an incident, including how fast they must tell you. A signed agreement is not a security control, but it is the document that governs what happens next, and the worst time to read it for the first time is after a confirmation lands. Our guide to what HIPAA breach notification actually requires covers the deadlines that would apply to you.

7. Ask the vendor directly, in writing

Contact your eAssist representative and ask for a security update in writing. eAssist has directed customer questions about the incident to its chief operating officer, and its September 8 notification said it will notify and provide guidance to affected parties based on what the investigation finds. Ask to be told what that finding is for your practice specifically, and ask when. An active investigation and legal review genuinely do limit what a representative can say, so a partial answer is not evidence of bad faith. Still, a vendor that cannot answer yet should say what it cannot answer and when it expects to. The communications we have reviewed give no target date for a practice-specific answer and no update schedule, which is part of why we now recommend evaluating an alternative provider rather than waiting for the next renewal conversation.

8. Tell your front desk what to expect

This one is standing hygiene as much as a response to this incident, and it is worth a two-minute huddle whenever any vendor breach is in the news. If patient details ever do circulate, the symptom that reaches your office is a convincing phone call: someone claiming to be from your practice or an insurer, armed with real information. Your team should know that a caller knowing a patient’s details does not make them legitimate. If your practice’s data turns out to be involved, our guide on what to do after a breach walks through the sequence.

The vendor question this should actually raise

Do not let this end with eAssist. The reason this incident is worth this much attention is that a billing vendor sits in a position most dental groups have never risk-assessed: outside your walls, inside your systems, holding data for many practices at once.

You almost certainly have several vendors in that position. Your clearinghouse, your imaging platform, your patient communication tool, your analytics dashboard. Any of them could be next month’s leak site post, and the eight steps above would not change. It is why the biggest dental data breaches on record are, by people affected, mostly incidents at vendors and payers rather than at practice networks.

The groups that handle these weeks calmly are not the ones with better threat intelligence. They already know which vendors touch patient data, already scoped that access to the minimum, and already monitor for data leaving. For a DSO that work compounds, because vendor sprawl multiplies with every acquisition, and each practice you buy arrives with its own billing arrangement and its own uninventoried integrations. It is the difference between answering this question in an afternoon and spending three weeks discovering what you are connected to.

eAssist Data Breach FAQs

Has eAssist confirmed a data breach?

eAssist has acknowledged that data was exfiltrated from an eAssist system, according to customer communications shared with us. Those same communications say the investigation has not established which customers or patients may have been affected. On September 8, 2026 eAssist first notified customers that it was investigating a potential information security incident with outside experts engaged. Whether data left eAssist’s system and whether your practice’s patient information was involved are separate questions, and the second one is unresolved rather than cleared. In September, the Georgia Dental Association’s advisory told practices not to assume a reportable HIPAA breach had occurred while the investigation runs. With exfiltration now acknowledged, have your HIPAA advisor make the breach-notification assessment for your practice. Keep every notice you receive from eAssist.

What data was taken in the eAssist breach?

According to the attacker’s listing, and only according to it: insurance portal logins, per-office software and remote access credentials, EOB and claims records with patient details, provider onboarding files, and a large volume of eAssist’s own accounting, payroll and hiring data, about 12.8 million database rows in all. eAssist has not confirmed any of it. The categories that matter to a practice are the credentials and the claims data, covered above.

When did the eAssist breach happen?

The listing went up on September 6, 2026. Neither the attacker nor eAssist has said when the intrusion itself occurred, and leak site listings typically follow the intrusion by days or weeks, after a ransom demand goes unanswered. Treat September 6 as the date the claim became public, not the date of the breach.

Is eAssist owned by Henry Schein?

Yes, majority owned. Henry Schein announced on June 10, 2021 that it had acquired a 70% ownership position in eAssist Dental Solutions. eAssist continues to operate under its own brand.

Was patient data exposed in the eAssist breach?

That has not been established either way. eAssist’s more recent customer communications acknowledge that data was exfiltrated from an eAssist system, but say the investigation has not established which customers or patients may have been affected, and there is no public, independently verified answer. On September 8, 2026, eAssist’s position was that it had not confirmed customer or patient information was accessed and that no specific records, credentials or patient data types had been verified as exposed. A later notice to former customers added that credentials used by eAssist staff may have been among the data potentially involved. That is a reason to rotate them, not a confirmation of exposure. DireWolf’s listing describes roughly 530,000 EOB and claims records carrying patient names, dates of birth and payer details, but no independent source has confirmed that any of it exists, and the tracker record for the listing shows no data volume in the field where one would normally appear. eAssist handles claims and billing data for dental practices, so patient information is plainly within reach of its systems, but reach is not evidence. Treat the question as unresolved rather than cleared, and act on your own access controls rather than on an assumption in either direction.

Should we terminate eAssist over this?

We now recommend evaluating an alternative billing provider. Our earlier answer was no, because exposure was unconfirmed: eAssist had acknowledged an investigation and said staff credentials may have been involved, but had not said that data left its systems. Its later communications acknowledge exfiltration, and the ones we reviewed still give practices no practice-specific answer or a date for one. Evaluating a replacement is not an emergency exit. Switching billing vendors mid-cycle carries its own operational risk, so plan an orderly transition with your billing continuity protected, as described in the October update above. Switching also does not undo any exposure that may already have occurred, so keep tightening and verifying eAssist’s access in the meantime.

Do we have to notify patients about this?

That depends on facts the public record does not yet show, which is why it belongs with your HIPAA advisor or counsel now. Notification obligations run from the discovery of a breach of unsecured protected health information. eAssist has acknowledged that data was exfiltrated from one of its systems, but the communications we reviewed do not establish which practices or patients were affected. If eAssist was acting as your business associate, it must notify you of a breach of unsecured protected health information it holds for you without unreasonable delay and no later than 60 days after discovery, and your own obligation to notify patients does not disappear because the incident happened on someone else’s systems. Locate your business associate agreement, keep every notice and response, and let your advisor assess where your obligations stand.

How do I know if my practice was affected by the eAssist breach?

Not from anything public yet. eAssist now acknowledges that data was exfiltrated from an eAssist system, but no verified list of affected practices is public and, according to its customer communications, the investigation has not established which customers or patients may have been affected. Ask eAssist in writing whether your data or credentials were stored on the affected system and whether your practice’s involvement has been ruled out. What you can establish today is your own exposure: whether you send data to eAssist, what data that is, and what access their people and systems have inside yours. If a confirmation does come, that inventory is what turns a vague worry into a specific, answerable question.

How credible is DireWolf?

Credible enough to take seriously, not credible enough to quote. A group in this business has a reason not to invent victims outright, because a listing that gets publicly disproven costs it leverage on the next target. It has an equally clear reason to inflate the value of what it took, because that is the number doing the negotiating. Treat the fact of the listing as the signal and the inventory attached to it as marketing.

Dental practices do not need to wait for a final investigative report to decide what level of vendor risk they are willing to accept. Continued access should be supported by current evidence, clear communication and accountability.

That is the work we do for the dental groups and DSOs we protect at Medix Dental IT. We map every vendor and integration that can reach patient data, scope that access down to what each role actually needs, and monitor for the credential abuse and bulk data access that can follow a vendor compromise. If you want a second set of eyes on how exposed your vendor chain makes you, a cybersecurity assessment is the place to start.

Posted in Dental Cybersecurity, News