The Admin Password
Was 1234.
The Vendor Set It.

The Password Was 1234

I'm going to tell you something that should make every dental practice owner in South Africa deeply uncomfortable — and then I'm going to tell you exactly what to do about it.

During a security assessment of a dental practice, I found a set of credentials granting full administrative access to the practice management system. Not partial access. Not a read-only view. Full admin — patient records, billing data, treatment histories, ID numbers, the entire database. Everything the practice had ever recorded about every patient it had ever treated.

The password protecting all of that was 1234.

The practice owner was sitting three metres away when I found it. They had no idea.

Here's the part that changes this from a cautionary tale into something more serious: the practice owner didn't set that password. The software vendor did. It had been placed there — hardcoded into the installation — to allow the vendor's support team to access the system remotely without needing to ask the client for credentials every time.

Convenient for the support desk. Catastrophic for the practice.

Who Set It — And Why

To be clear about what happened here: this was not the practice owner cutting corners. This was not a lazy receptionist using a simple password. This was a decision made by the software vendor — a decision to embed a standing backdoor into their product under the banner of "remote support."

This practice is common in the dental software space, and wider healthcare IT. Vendors build their products with pre-configured admin accounts — sometimes called service accounts, sometimes just "support" logins — that allow their technicians to connect to a client's system without going through the normal authentication process. The logic is straightforward: if something goes wrong and the practice can't log in, the vendor needs a way in.

The problem is that "a way in for us" is also "a way in for anyone who knows about it." And default credentials are not a secret. They are shared among support teams, documented in internal wikis, sometimes included in installation guides, and frequently discovered by attackers who scan for known software and test standard defaults. The credentials for a given product's support backdoor are often published on hacking forums before the product has even been deployed at scale.

The Attacker's Workflow

Here is what the exploitation of a default credential looks like from the attacker's perspective — not a sophisticated, multi-stage operation, but a matter of minutes:

Notice what's missing from that sequence: complexity. There's no exploit code. No zero-day vulnerability. No sophisticated social engineering. Just a known credential, entered into a login field. The barrier was effectively zero.

What Was Actually Exposed

When I say "full admin access to the practice management system," I want to make sure the weight of that is clear. This is not like having the password to a shared email account. A dental practice management system is one of the most data-rich environments a small business can operate. Through that single set of credentials, the following data was accessible:

• Full patient identity data — names, ID numbers, dates of birth, contact details, addresses
• Medical and dental histories — treatment notes, diagnoses, medications, allergies, clinical photographs
• Financial records — billing histories, medical aid details, scheme numbers, payment records
• Staff data — employee information, schedules, access credentials for other system functions
• Business intelligence — appointment volumes, revenue data, supplier relationships

Every single one of those categories is explicitly protected under the Protection of Personal Information Act (POPIA). Medical information, in particular, is classified as a special category of personal information — the most protected category in the Act — requiring the highest standard of care in its collection, storage, and processing.

The Supply Chain Nobody Talks About

There's a broader problem here that goes beyond this single incident. Healthcare practices in South Africa — dental and medical alike — tend to focus their security attention on the threats they can see: phishing emails, suspicious USB drives, ransomware warnings in the news. What they don't typically examine is the security posture of the software and vendors they've invited into their networks.

Your practice management software has access to everything. It runs on your server. It stores your patient database. It may communicate with external cloud services, your medical aid clearinghouse, your PACS imaging system. The vendor who built it and supports it has, by necessity, deep integration with your most sensitive infrastructure.

That vendor is part of your attack surface — whether or not they appear on any risk register you've ever seen.

Questions Every Practice Should Be Asking

When last did you ask your dental software vendor the following questions:

• Are there any default, shared, or vendor-managed credentials in our installation?
• How does your support team access our system remotely — and what authentication controls are in place?
• Has your software been independently security-audited? When, and by whom?
• What data does your software transmit externally, and how is it encrypted in transit?
• What is your breach notification process if your systems are compromised and it affects our data?

If you've never asked those questions, you are not alone. Most dental practices haven't. But the absence of that conversation doesn't reduce your legal exposure — it just means you may not know about a problem until after it's become a breach.

Your POPIA Exposure

South Africa's Information Regulator has made it clear that POPIA is not aspirational guidance. It is the law. And the law is structured in a way that places the regulatory obligation squarely on the practice — not on the vendor, not on the software company, and not on whoever set the original password.

As the responsible party under POPIA, your practice is accountable for the security of personal information in its possession. If that information is accessed without authorisation — even if the vulnerability was created by a third party you trusted — the breach notification obligation is yours.

The 72-Hour Rule

Section 22 of POPIA requires responsible parties to notify the Information Regulator and, in many cases, the affected data subjects (your patients) of a breach "as soon as reasonably possible" after becoming aware of it. In practice, the expectation aligned with international norms is 72 hours. That is not 72 hours to fix it — it is 72 hours to notify, even if the investigation is still ongoing.

Consider what that means in context: if a default credential on your system was discovered and exploited by an attacker — silently, with no trace in any log you checked — you may not even know a breach occurred. The first indication might come from a patient complaint, a dark web alert, or an investigation triggered by something entirely unrelated. At that point, you are already outside the notification window.

What To Do Right Now

I'm not writing this to frighten you. I'm writing this because I know exactly what the inside of a dental practice looks like, and I know that most practitioners are doing their best with limited time and limited IT support. The vulnerabilities that exist in most practices are not the result of negligence — they are the result of a threat environment that has evolved much faster than the guidance given to healthcare professionals.

But knowing about it and doing nothing is a different matter entirely. Here's what you can do today:

1. Ask Your Vendor Directly

Call or email your dental software vendor's support line right now and ask: "Are there any default, shared, or vendor-managed login credentials on our installation?" Document the response. If the answer is yes, or if they can't give you a clear answer, escalate. You have a right to know what credentials exist on your system.

2. Conduct a Credential Audit

Log into your practice management software as an administrator and review every user account in the system. Look for accounts you don't recognise, accounts without a named person attached, or accounts with obvious default passwords. Disable or delete anything that cannot be attributed to a specific, current staff member.

3. Enable and Review Remote Access Logs

If your software supports remote access by the vendor, ensure that logging is enabled for all remote sessions. You should be able to see when the vendor (or anyone else) connects, what they did, and how long they were active. If that logging doesn't exist or can't be enabled, treat it as a red flag and raise it with the vendor in writing.

4. Change Every Default

Every account that was created during installation — every default username, every example password, every "admin" account that was part of the original setup — should have its credentials changed to something complex, unique, and known only to you. Enable multi-factor authentication wherever the software supports it. Do this today, not at your next IT maintenance window.

5. Get an Independent Assessment

The fact that you didn't know about a vulnerability doesn't mean it doesn't exist. A professional security assessment of a dental practice environment will examine your software installations, your network configuration, your access controls, and your vendor relationships — and will tell you exactly what an attacker would find if they looked at your practice the way I look at my clients' practices.