TL;DR

Most cloud breaches don't come from genius hackers — they come from over-permissioned accounts and forgotten access keys. If your team hands out AdministratorAccess like candy or has root credentials sitting in a spreadsheet, you're one credential leak away from a breach. Fix three things this week: lock down root accounts, enforce MFA everywhere, and replace long-lived access keys with temporary credentials. That alone closes the door on the majority of cloud attack paths.​‌‌​​​‌‌‍​‌‌​‌‌​​‍​‌‌​‌‌‌‌‍​‌‌‌​‌​‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​‌​​‌‍​‌‌​​​​‌‍​‌‌​‌‌​‌‍​​‌​‌‌​‌‍​‌‌​‌‌​‌‍​‌‌​‌​​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​‌‌​​​​‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌‌​

The Problem Nobody Talks About at SMB Board Meetings

You moved to the cloud because it was faster, cheaper, and someone promised "military-grade security." Here's what they didn't say: 99% of cloud security failures through 2026 are your fault — not AWS, Microsoft, or Google's. That stat comes from Gartner, not a vendor sales deck. And the number one failure point? Identity and Access Management — IAM for short.

IAM is the bouncer at the door of your cloud environment. It decides who gets in, what they can touch, and how long their key works. When it's set up wrong, attackers don't need to hack anything. They just log in.​‌‌​​​‌‌‍​‌‌​‌‌​​‍​‌‌​‌‌‌‌‍​‌‌‌​‌​‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍

​​‌​‌‌​‌‍​‌‌​‌​​‌‍​‌‌​​​​‌‍​‌‌​‌‌​‌‍​​‌​‌‌​‌‍​‌‌​‌‌​‌‍​‌‌​‌​​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​‌‌​​​​‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌‌​

The research backs this up. Cloud misconfigurations — most of them IAM-related — are the third most common initial attack vector in security breaches. Nearly half (45%) of organisations reported suffering at least four cloud-related incidents in the last 12 months. And 51% of organisations say phishing is the most common way attackers steal cloud credentials.

For a 15-person accounting firm in Parramatta or an e-commerce startup in Collingwood, that means the door is wide open.

Mistake #1: Treating the Root Account Like Just Another Login

Every cloud platform comes with a root account — the master key. AWS calls it the root user. Microsoft Entra ID has the Global Administrator. Google Cloud has the Super Admin.

What SMBs get wrong: They use the root account for daily work. Or they create it during setup, tie it to a shared email like [email protected], set a weak password, and forget about it.

Why it matters: If someone compromises your root account, they own your entire cloud environment. They can lock you out, delete backups, spin up $100,000 worth of crypto mining, and wipe the logs on the way out. The 2026 update to CISA's Known Exploited Vulnerabilities catalog shows attackers are increasingly targeting identity systems as the primary entry point — including the Cisco SD-WAN auth bypass (CVE-2026-20127, CVSS 10.0) that granted full admin access to networks for years before detection.

The fix (this week):

  • Lock root credentials in a proper password manager — not a spreadsheet, not a sticky note.
  • Enable hardware MFA (a YubiKey or similar) on the root account.
  • Never use root for daily tasks. Create individual user accounts for every person.
  • Remove root API access keys entirely. Root should never make programmatic calls.

Mistake #2: Granting AdministratorAccess Because "It's Easier"

Walk into most SMB cloud environments and you'll find half the users running with AdministratorAccess in AWS, Global Administrator in Entra ID, or Owner in GCP. The reason is always the same: "We're a small team, and it got in the way."

What SMBs get wrong: They mistake small team size for small attack surface. It doesn't matter if you have three employees — if any of them gets phished, the attacker now has admin access to everything. 51% of organisations report phishing as the top credential theft method. One email click by your bookkeeper, and suddenly someone in Minsk is deleting your customer database.

Why it matters: Least privilege is not a compliance checkbox. It's the difference between a contained incident and a catastrophic breach. When an account can only access what it genuinely needs, a compromised credential doesn't give the attacker the keys to the kingdom.

The fix (this week):

  • Audit every existing user and list their attached policies. If you see AdministratorAccess, Global Administrator, or Owner, flag it.
  • Replace admin policies with job-specific ones: your marketing person doesn't need database delete permissions.
  • Use AWS IAM Access Analyser or Entra ID's access reviews to see what permissions people actually use — and remove the rest.
  • Start with AWS managed policies like ReadOnlyAccess or PowerUserAccess as a step down from full admin, then tighten further.

Mistake #3: Long-Lived Access Keys Sitting in Plain Text

The third mistake is so common it's almost a cliché: access keys hard-coded in config files, buried in GitHub repos, or emailed around the team. These long-lived credentials never expire and often belong to users who left the company six months ago.

What SMBs get wrong: Service accounts and user accounts get treated the same. An application that needs to upload files to S3 gets a permanent IAM user with an access key, and that key gets pasted into a .env file that someone accidentally commits to a public repository.

Why it matters: Long-lived credentials are a ticking bomb. AWS, Entra ID, and GCP all support temporary credentials through their respective security token services (STS, managed identities, workload identity federation). Temporary credentials expire — usually within an hour. If an attacker steals one, they have a very short window to do damage. If they steal a permanent access key, they have until someone notices.

The fix (this week):

  • Service accounts vs user accounts: Applications and automated tasks should never use IAM user credentials. They should use IAM roles (AWS), managed identities (Entra ID), or service accounts (GCP) — all of which issue temporary credentials automatically.
  • Rotate and delete: Find every existing long-lived access key and set an expiry date. Better yet, delete them and migrate to role-based access immediately.
  • For on-prem workloads: Use AWS IAM Roles Anywhere or Azure Arc to issue temporary credentials without long-term secrets.
  • Cross-account access: When you need services in different accounts to talk to each other, use role assumption (not shared credentials). It's the difference between lending someone a copy of your house key versus meeting them at the door.

Your First-Week IAM Checklist

This isn't aspirational. Every item here can be done before Friday.

AWS IAM (Monday):

  1. Enable hardware MFA on the root account and remove all root access keys.
  2. Run IAM Access Analyser and review any findings showing overly permissive access.
  3. Create IAM roles for any application workloads currently using long-lived keys. Rotate the old keys out.

Microsoft Entra ID (Tuesday):

  1. Enable MFA for every user — conditional access policies make this easy.
  2. Review Global Administrator assignments. You should have no more than two.
  3. Enable Privileged Identity Management (PIM) so admin access is time-limited and just-in-time.

GCP IAM (Wednesday):

  1. Audit the IAM policy for your organisation node — remove any Owner or Editor roles that aren't strictly justified.
  2. Use service accounts with workload identity federation for any automated processes.
  3. Enable Security Command Centre's IAM recommender to find over-privileged accounts.

All platforms (Thursday):

  1. Disable or delete accounts for anyone who's left the business.
  2. Force password rotation for all users and ensure password policies meet complexity requirements.
  3. Run a credential scan across your code repositories (GitHub, GitLab, Bitbucket) for exposed access keys.

Verify (Friday):

  1. Attempt console login as root — it should require MFA.
  2. Run a report showing zero long-lived access keys older than 90 days.
  3. Confirm every human user has MFA and no hard-coded admin access.

FAQ

We're only a team of five. Do we really need all this?

Yes — probably more than a large enterprise does. Big companies have dedicated security teams, SIEMs, and 24/7 monitoring. You have five people. When a breach hits, you don't have a SOC to call. The IAM fundamentals cost nothing to implement and prevent the most common attack paths. A solo tradie can still get robbed because they left the front door unlocked.

What's the difference between a service account and a user account, practically?

A user account is for Karen in accounts payable. She logs in, checks invoices, and logs out. A service account is for the invoicing application itself — it runs automatically, never logs into a web console, and should use a role (not a username/password). If your developer's personal email gets phished, it shouldn't give the attacker access to your production database. That's why you separate them.

How do I handle cross-account access without sharing passwords?

Role assumption. In AWS, Account A creates a role with a trust policy allowing Account B to assume it. Account B's users (or services) call sts:AssumeRole and get temporary, scoped credentials. No passwords shared, no keys leaked, full audit trail. Azure and GCP have equivalent mechanisms (cross-tenant access and workload identity federation respectively).

What's the first thing I should do if I suspect a breach?

Revoke all active sessions immediately (all platforms have a "sign out everywhere" equivalent). Rotate every access key. Check CloudTrail / Entra ID audit logs / GCP Cloud Audit Logs for unusual API calls — look for AttachRolePolicy, CreateUser, AuthorizeSecurityGroupIngress, or anything happening from an unfamiliar IP range. Then call a professional. Visit consult.lil.business for a free initial cybersecurity assessment — we'll help you triage.

Conclusion

Cloud IAM isn't exciting, but it's the difference between a minor incident and an extinction-level event for your business. The three mistakes SMBs make over and over — root account neglect, blanket admin access, and permanent credentials — are exactly what attackers count on. They don't need a zero-day when you've left the front door unlocked.

This week: lock your root accounts. Turn on MFA everywhere. Audit every existing permission. Switch to temporary credentials. That's four afternoons of work that could save your business.

If you're reading this and thinking "I don't know where to start" — that's normal. The cloud platforms give you 10,000 knobs and dials. Visit consult.lil.business for a free 30-minute cloud security assessment. We'll look at your IAM setup, tell you what's broken, and give you a prioritised fix list — no jargon, no upsell, just practical help for Australian small businesses.

References

  1. AWS IAM Security Best Practices (Official Documentation)
  2. Gartner: Through 2026, 99% of Cloud Security Failures Will Be the Customer's Fault
  3. ACSC Essential Eight Maturity Model — Multi-Factor Authentication
  4. Cloud Misconfiguration: The #1 Cause of Data Breaches — Fidelis Security
  5. CISA Known Exploited Vulnerabilities Catalog

TL;DR

  • A company called Conduent that works for the government got hacked
  • 25 million people had their personal information stolen (that's like the whole population of Australia!)
  • The bad guys hid inside Conduent's computers for 3 months before anyone noticed
  • This teaches us: the companies YOU rely on can put YOUR data at risk

What Is Conduent? (And Why You've Probably Never Heard of Them)

Imagine you order pizza online. You talk to the pizza place's website, but behind the scenes, they use:

  • A delivery app to track drivers
  • A payment company to process your credit card
  • An email service to send your receipt

You don't see these companies. You just know "I ordered pizza and it showed up."

That's Conduent. They're a "back-office" company that does boring but important work for:

  • Governments (processing Medicaid, food stamps, and other benefits)
  • Health insurance companies (handling claims and paperwork)
  • Big businesses (processing payroll and HR stuff)

Over 100 million people rely on services that Conduent runs, but most people have never heard their name [1].

What Happened?

Bad guys broke into Conduent's computers and stayed there for 84 days (almost 3 months!) from October 2024 to January 2025 [2].

During those 84 days, the hackers:

  • Wandered around Conduent's computer systems
  • Downloaded 8.5 terabytes of data (that's like 2 million photos!)
  • Stole personal information from 25 million people

Think of it like a burglar breaking into your house, living there for 3 months, eating your food, wearing your clothes, and slowly carrying out all your valuables — one box at a time so nobody notices.

Who Got Hurt?

At first, Conduent thought only 10 million people were affected. But as they investigated more, the number grew to 25 million [3].

Here's who got hit:

  • People in Texas: 15.4 million (that's half the state!)
  • People in Oregon: 10.5 million
  • Volvo employees: 17,000 workers
  • Blue Cross Blue Shield members: in multiple states
  • People on Medicaid or food stamps: in over 30 states [2][3][4]

Many of these people didn't even know Conduent existed. They just knew "I get my health insurance through Blue Cross" or "I apply for benefits through a state website."

What Did the Hackers Steal?

The hackers didn't steal credit card numbers (that would be too simple). They stole forever data — information that can't be changed:

  • Social Security numbers (your permanent ID number)
  • Birthdates
  • Home addresses
  • Medical records and health insurance info
  • Government benefit records [2]

With this information, bad guys can:

  • Open fake credit cards in your name
  • File fake tax returns and steal your refund
  • Get medical treatment using your insurance
  • Apply for government benefits pretending to be you

This isn't like stealing a password you can change. This is stealing your identity.

The Big Problem: Dwell Time

The scariest part isn't that 25 million people were affected. It's that the hackers hid inside Conduent's systems for 3 months before anyone noticed.

This is called "dwell time" — how long bad guys can hide before they get caught.

Imagine a stranger living in your attic for 3 months. Every night, they come down, take stuff, and go back up. You wouldn't know until you notice things are missing.

That's what happened to Conduent. The hackers were inside for 84 days, stealing data slowly so no alarm would go off.

Why this matters:

  • More time inside = more data stolen
  • More time inside = more time to learn the system
  • More time inside = more time to set up secret back doors

According to security experts, the average hacker hides inside company systems for 7 months before getting caught [5]!

How Does This Affect Your Business?

You might not work with Conduent directly. But you probably rely on other companies to do important work for your business:

  • Accountants who see your financial data
  • Cloud services that store your files
  • Shipping companies that handle customer addresses
  • Software tools that process customer information

If ANY of these companies gets hacked, YOUR data is at risk — even if your own computers are perfectly secure.

It's like leaving your bike locked at a friend's house. Your lock works great. But if your friend's house gets robbed, your bike is gone.

The Warning Signs to Watch For

You can't prevent vendor breaches, but you CAN spot them faster. Watch for these red flags:

1. Weird letters or emails from companies you don't recognize If you get a letter about a "data breach" from a company you've never heard of (like Conduent), don't throw it away. It might be about YOUR data, handled by a vendor you didn't know existed.

2. Vague messages about "security incidents" If a company sends a generic "we had a security issue" message without details, ask:

  • What happened?
  • When did it happen?
  • Was my data stolen?
  • What are you doing to fix it?

If they can't answer, that's a bad sign.

3. Delays in telling you about problems Conduent discovered the breach in January 2025 but didn't tell everyone until months later [2]. If a company takes a long time to notify you about a problem, it might mean:

  • They don't understand what happened
  • They're trying to hide how bad it is
  • They're still investigating

All of these are bad for your business.

What You Can Do (3 Simple Steps)

Step 1: Make a list of who has your data Write down every company that handles important information for your business:

  • Customer names and emails
  • Payment information
  • Employee records
  • Tax or financial documents

Keep this list safe. You'll need it if something goes wrong.

Step 2: Ask your vendors tough questions Before you share important data with a company, ask them:

  • "What happens if you get hacked?"
  • "How will you tell me if my data is stolen?"
  • "Do you have insurance to help if something goes wrong?"
  • "How do you protect your computers?"

If they can't answer these questions, find a different vendor.

Step 3: Have a plan BEFORE something goes wrong If a vendor called you TODAY and said "We were hacked and your data was stolen," what would you do?

  • Who would you call?
  • How would you tell your customers?
  • Do you have backup copies of important files?
  • How would you check if bad guys are pretending to be you?

Write this plan down NOW. Don't wait until it happens.

The Most Important Lesson

The Conduent breach teaches us something important:

Your business's security is only as strong as the weakest company you work with.

You can have the best locks, alarms, and security cameras in the world. But if your accountant keeps your data on an unprotected laptop, or your cloud vendor has weak passwords, YOUR data is at risk.

This is why checking your vendors' security is just as important as securing your own business.

What Happens to the 25 Million Victims?

If you're one of the 25 million people affected by the Conduent breach, here's what you should do:

  1. Freeze your credit — This stops anyone from opening new accounts in your name (it's free in the US)
  2. Watch your mail — Look for official letters from Conduent or from companies that use Conduent
  3. Check your benefits — If you get Medicaid, food stamps, or other government benefits, make sure nothing has changed
  4. Be suspicious of emails — Scammers will pretend to be Conduent or the government to steal MORE information from you. Only trust official letters or websites you type in yourself

Conduent is offering free credit monitoring to some victims [2]. If they offer it to you, take it.

FAQ

If you received a letter from Conduent, or from a state agency or health insurer saying your data was "involved in a security incident" with Conduent, you're affected. You can also check if your email was leaked at haveibeenpwned.com, though this breach might not be listed yet because it's so new.

Hackers are good at hiding. They steal data slowly, use encrypted channels (like scrambling their messages), and delete logs of what they did. Conduent probably didn't notice anything unusual until months later when someone looked closely at their systems. This is why "dwell time" (how long hackers hide) is such a big problem — most companies find out MONTHS after the attack started [5].

Maybe. Some people are already filing lawsuits [6]. But lawsuits take years, and even if you win, you might not get much money. It's better to focus on protecting yourself NOW (freeze your credit, monitor accounts) than waiting for a lawsuit to help you later.

You can't — almost every company relies on vendors. Even your local grocery store uses payment processors, delivery services, and suppliers. Instead of avoiding vendors, focus on VETTING vendors (checking their security) and MONITORING vendors (watching for problems).

A terabyte (TB) is 1,000 gigabytes (GB). A typical smartphone photo is about 3-4 MB, so 1 GB = about 250 photos. Therefore:

  • 1 TB = 1,000 GB = 250,000 photos
  • 8.5 TB = 2,125,000 photos

But Conduent stores documents and databases, not photos. So 8.5 TB of data could be:

  • Millions of pages of documents
  • Database records for tens of millions of people
  • Years of emails and files

It's a LOT of information — enough to fill a whole library.

References

[1] Malwarebytes, "The Conduent breach; from 10 million to 25 million (and counting)," February 2026. [Online]. Available: https://www.malwarebytes.com/blog/news/2026/02/the-conduent-breach-from-10-million-to-25-million-and-counting

[2] GovInfoSecurity, "Conduent Says Hack Now Affects at Least 25 Million Patients," February 2026. [Online]. Available: https://www.govinfosecurity.com/conduent-says-hack-now-affects-at-least-25-million-patients-a-30848

[3] Texas Attorney General, "Texas AG Investigating Conduent Hack," February 2026. [Online]. Available: https://www.texasattorneygeneral.gov/news/releases/texas-ag-investigating-conduent-bcbs-texas-hack

[4] Volvo Group, "Volvo Employee Data Exposed in Conduent Breach," February 2026. [Online]. Available: https://www.volvogroup.com/en-en/news/volvo-employee-data-exposed-conduent-breach

[5] CrowdStrike, "2025 Global Threat Report: Average Dwell Time 212 Days," CrowdStrike, 2025. [Online]. Available: https://www.crowdstrike.com/global-threat-report/

[6] Edelson Lechtzin LLP, "Conduent Data Breach Investigation," 2026. [Online]. Available: https://www.globenewswire.com/news-release/2026/03/08/3251423/0/en/DATA-BREACH-ALERT-Edelson-Lechtzin-LLP-is-Investigating-Claims.html

Your vendors are your business's biggest risk. lilMONSTER helps you check them, make a plan, and protect your customers. Book a free consultation at https://consult.lil.business?utm_source=blog&utm_medium=post&utm_campaign=conduent-eli10

Ready to strengthen your security?

Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

Get a Free Consultation