When £20,000 Vanishes: The Hidden Cost of Password Reuse and SIM Swaps

A few months ago, a family member of mine was defrauded out of almost £20,000. Thankfully, the money was eventually recovered, but the damage went far beyond the financial loss. Their trust in online banking and technology was shattered. Every login, every "security" text, and every email now feels like a potential trap.

The worst part is that it could have been prevented, both through better personal security habits and stronger authentication by the bank.

How It Happened

It started with password reuse, the silent killer of digital security. The credentials were stolen from some long-forgotten online service, one of those pointless accounts that had not been used in months, but the password was the same one used elsewhere.

Those details ended up for sale on the dark web. Attackers used them to access the victim’s mobile provider account and carry out a SIM swap, moving the phone number to a new device.

Once they controlled the number, everything else fell apart. The attackers intercepted text messages, reset online banking credentials, and authorised a £20,000 transfer, all through SMS verification.

No step-up authentication.
No confirmation call.
No "this looks suspicious" flag.

Just one recycled password and one text message.

For a five-figure transaction, that is beyond negligent!

Convenience Over Security

Banks love to talk about balancing convenience and security, but that balance has tipped too far. SMS-based authentication has not been fit for purpose in years, yet it remains the default method for major transactions.

At my bank, a transfer of that size would have triggered secondary verification, an app confirmation, biometric approval, or at least a voice check. The bank in this case did none of that. It is not that they could not, it is that they did not.

When fraud prevention becomes a tick-box exercise instead of a real control, customers end up paying the price, both financially and emotionally.

The Aftermath: Weeks of Fallout

Even after the refund, the cleanup has been brutal. Weeks spent combing through credit reports, checking for new accounts or applications, and manually changing credentials across every major account, from banking to utilities, retail, and entertainment.

It has been a complete ballache.

Fraud does not end when the money comes back. The admin and anxiety drag on long after. For someone who is not in IT, the psychological damage is huge. My family member went from confident and capable to hesitant and suspicious of everything online.

They have now decided to move back to a bank they can walk into, somewhere they can see a face, talk to a person, and feel a bit more secure. Honestly, I cannot blame them.

Lessons Learned

SMS is not security. It is the weakest form of multi-factor authentication and should be retired, not relied upon.
Risk-based authentication matters. A £20,000 transfer needs more than a text message.
Stop reusing passwords. A password manager is far safer and simpler than remembering multiple variations of the same one.
Lock down your mobile account. Add a porting PIN or passphrase, every UK carrier supports this.
Monitor your credit file. Fraud rarely stops at one account.
Never assume your bank has your back. Some still operate as if it is 2008.

The Bigger Problem

Banks continue to invest millions in "AI-driven fraud detection" while still relying on 1980s telecom infrastructure to secure customer savings. They will happily refund fraud cases but rarely address the systemic weaknesses that make them possible in the first place.

They do not measure the emotional impact, the time lost, or the erosion of trust. They simply mark the case as resolved.

Fraud prevention should not end with a refund. It should begin with authentication that actually works.

The Takeaway

This was not a sophisticated cyberattack. It was a familiar story that happens daily: password reuse, outdated SMS verification, and complacency disguised as convenience.

The money came back, but the confidence did not.

The lesson is simple. Never let your phone number be your last line of defence, and never assume your bank’s idea of "secure" matches yours.

by Jay Ralph

Stop Emailing Like It’s 2013: Microsoft Is Finally Pulling the Plug on @onmicrosoft.com

If you’ve still got mailboxes or services firing off emails from something@yourtenant.onmicrosoft.com, consider this your polite nudge (well, Microsoft’s) to stop.

Because in classic Microsoft fashion, it’s not just a suggestion anymore — they’re throttling it.

Yes, seriously!

The Change

Starting October 15, 2025, Microsoft will start throttling outbound email sent from .onmicrosoft.com addresses to 100 recipients per tenant, per day. It’s a phased rollout, with full enforcement by June 2026.

After that? Every message over the limit gets bounced faster than your expense claim for a “technical lunch” at Gaucho.

🧾 Full details here on TechCommunity

Why the Sudden Crackdown?

To be fair, Microsoft’s letting you down gently. The reasons behind this move are solid:

Shared reputation – Your .onmicrosoft.com domain shares an IP rep with every other tenant. That includes legitimate businesses… and also dodgy spam farms.
Trust and branding – No one feels good getting an invoice from accounts@widgets-inc.onmicrosoft.com. It just doesn’t inspire confidence.
Security – Spoofing an onmicrosoft.com address is relatively easy for attackers. This change makes that harder — and forces orgs to clean up their setup.

What Actually Breaks?

Here’s the fun bit: it’s per tenant, not per user.

So if multiple users or automated services are still sending from @onmicrosoft.com, you’ll all be queuing for that same 100-email daily allowance. Go over, and Microsoft slaps you with this lovely NDR:

550 5.7.236 – Message rejected due to sending limits.

That means:

Support mailboxes stop replying
CRM notifications don’t arrive
Your legacy scanner in Accounts can’t send its daily scan of someone’s elbow

What You Should Be Doing Instead

This really shouldn’t be news. But hey, if your setup still leans on the freebie domain, here’s your to-do list:

✅ Register a Real Domain

Use something official — ideally the same domain your users sign into.
No myrealbusinesssolutions365v2.biz, please.

✅ Add It to Microsoft 365

Go to Admin Centre > Settings > Domains and follow the prompts.
Set up your DNS records — SPF, DKIM, DMARC — all the good stuff.

✅ Set As Default

Make sure new users and services get assigned your real domain automatically — not @onmicrosoft.com.

✅ Fix Existing Mailboxes

Use PowerShell to change addresses:

Don’t forget to double-check login UPNs and app dependencies.
One careless change and suddenly half your staff can’t log into Teams.

✅ Audit Everything Sending Mail

Check for services, apps, Power Automate flows, old scanners, or hybrid mail relays still sending from the wrong domain. Microsoft’s Message Trace or Defender XDR can help.

But… Why Was I Using It Anyway?

Short answer: because it was easy.
Long answer: it was easy 10 years ago.

The .onmicrosoft.com domain was always meant to be a placeholder — for testing, tenant setup, and temporary use. Not for external mail, marketing comms, or service account spam.

Would you send corporate mail from yourbusiness@hotmail.com?
(…don’t answer that if you’re still doing it.)

Bonus Round: Do Some Security While You’re There

While you're cleaning up your domain usage, it’s a great time to:

✅ Set up SPF to say who can send on your behalf
✅ Enable DKIM to sign your mail
✅ Configure DMARC so spoofers get blocked
✅ Add a Transport Rule to stop future sends from .onmicrosoft.com just in case someone tries again

You’ll sleep better at night — promise.

Final Thought

If you haven’t sorted this already, don’t worry — there’s still time. But make no mistake, this change is coming whether you’re ready or not. And while fixing it might feel like a chore, not fixing it is worse.

Avoid outages, broken processes, and embarrassing email bounces.
Use a real domain. Email like a grown-up.

Your support desk will thank you. And so will your customers.

TL;DR

Microsoft is throttling .onmicrosoft.com email sends from October 2025
The cap is 100 recipients per tenant per day
Use your real domain — now
Audit your setup and fix anything that sends from the default tenant domain
Update SPF/DKIM/DMARC while you’re there

by Jay Ralph

MDM Isn’t Enough: Why You Still Need a Real Security Strategy

You’ve deployed Intune. Devices are enrolling, compliance policies are lighting up green, and someone’s gone full hero mode because Defender says your estate is “secure.”

Sorry to be that guy, but: MDM isn’t the endgame. It’s the start line!

In 2025, modern attackers don’t care about your BitLocker compliance. They’re jumping across cloud sessions, hijacking tokens, exploiting stale service accounts, and laughing at environments that think mobile device management equals a security strategy.

Let’s unpack why MDM on its own is dangerously incomplete — and what a real enterprise security posture should look like.

MDM: Great at Policy, Awful at Visibility

Intune and other MDM platforms (like JAMF, Workspace ONE, or MobileIron) are brilliant for configuration. They enforce device settings, deploy apps, and ensure a certain level of hygiene across your fleet. But what they don’t do is monitor, detect, or respond to threats.

They’re like a bouncer checking IDs at the door, but once someone’s inside, they’re not watching the room.

MDM can:

Enforce encryption (BitLocker/FileVault)
Require a PIN or biometric login
Set compliance policies for OS version, AV, etc.
Deploy apps and apply device restrictions

MDM can’t:

Detect lateral movement or token replay
Analyse cloud sign-ins and behavioural anomalies
Prevent data exfiltration in real-time
Intervene during an active attack
Correlate endpoint and identity risk

If your estate is “secure” because Intune says it’s compliant, you’ve got a false sense of safety. And that’s worse than none at all.

Common MDM-Only Mistakes We Still See

1. Conditional Access with More Holes Than Swiss Cheese

Let’s say you’ve deployed CA policies – brilliant. But then come the exclusions:

“We’ll skip MFA for VIPs”
“This app doesn’t support modern auth, just allow it”
“Printers can’t do Conditional Access, so bypass them”

You’ve just created your own attack surface, piece by piece. Attackers love legacy – they’ll happily sidestep your security by abusing the same gaps you made for “convenience.”

2. Assuming Defender Antivirus Is the Same as Defender for Endpoint

Built-in AV? Great. But where’s your threat intel? Where’s the behavioural analysis? Where’s the 24/7 monitoring?

If you’re not backing MDM with Defender for Endpoint (Plan 2) or an equivalent EDR/XDR stack, you're blind to what’s happening after login.

3. Admins with Too Much Access, For Too Long

Let’s be crystal clear - A Global Admin in Entra ID (Azure AD) isn’t just a Microsoft 365 superuser — they’re a tenant god.

With the right API access, a Global Admin can:

Delete users, data, and services
Change or remove security policies
Modify Conditional Access rules
Reset other admins’ credentials
Delete your entire Azure subscription

Yes, really. If you’re integrated with Azure and using a CSP or enterprise subscription, GA rights extend across Microsoft 365 and Azure. One compromised GA account can lead to full platform loss, including compute, networking, identity, and storage.

So if you're handing out GA because someone “needs to make a mailbox,” you’re putting your entire estate on the line.

Security tip:

Adopt a Least Privilege Model – Only assign the minimum permissions needed for the task. Most users don’t need GA. Most IT staff don’t either. Delegate roles like Exchange Admin or Security Reader instead.
Use Privileged Identity Management (PIM) – Just-in-time access with approval, MFA, timeouts, and justification. No more standing admin rights.
Separate Admin Accounts – Never allow daily-use accounts to have admin privileges. Admin accounts should be isolated and used only when required.
Enforce MFA on All Admin Roles – And audit for any exclusions. MFA should be non-negotiable.
Monitor Admin Sign-Ins – Set alerts on Global Admin activity, especially from new locations or devices.
Review Access Regularly – Make it part of your quarterly checks. If someone doesn’t need GA anymore, revoke it.

In short: If one compromised login can delete your entire subscription… you don't have a secure environment.

4. Zero Control Over App Updates

Intune can deploy apps, sure. But who’s updating them? Your 500-user estate might be rocking:

Chrome v91
Java runtimes from 2016
12 versions of Zoom

Modern attacks are exploiting apps more than OS. If you’re not automating third-party patching with Intune Suite, Patch My PC, or Chocolatey, you're living on borrowed time.

What You Actually Need: A Layered Security Strategy

Security isn’t one tool. It’s an architecture. A mindset. A set of non-negotiables backed by automation, not best guesses.

Here’s what a real security stack for modern management looks like:

Layer	Tooling Example	Purpose
MDM & Compliance	Intune, JAMF	Enforces baseline device hygiene
Access Control	Conditional Access, PIM	Ensures right access at the right time
Threat Detection	Defender XDR, Sentinel, Splunk	Detects, analyses, and correlates suspicious activity
Identity Protection	Entra ID Protection	Flags risky users, impossible travel, sign-in anomalies
App Management	Patch My PC, Intune Suite, Chocolatey	Keeps apps secure and updated
Data Protection	TLS 1.2/1.3, Purview DLP	Protects data in transit and at rest

This isn't just "nice to have" anymore. With hybrid work, BYOD, and cloud services everywhere, your devices are exposed all the time.

But What About BitLocker PINs and BIOS Lockdown?

Let’s have the honest conversation: BitLocker PINs sound good on paper, but in practice, they’re a user - hostile security placebo.

Sure, they add an extra hurdle at boot — but let’s be real: most of your threats aren’t sitting in car parks with a crowbar and 30 minutes to brute-force a laptop. And if they are? A six-digit PIN isn't stopping them.

What a BitLocker PIN actually does:

Slows down boot time and frustrates users (especially in policing, healthcare, or emergency services).
Adds support overhead when someone forgets it at 5am.
Gives a false sense of protection against physical threats.

And what it doesn’t do:

Prevent nation-state or skilled attackers with physical access from getting in.
Stop firmware-level attacks, bus sniffing, or TPM-side exploits.
Protect against 99% of real-world threats — like phishing, token theft, or lateral movement.

If you’re relying on a boot PIN for security, you’re fighting yesteryear’s threats. Most data theft today isn’t someone stealing a laptop – it’s someone phishing credentials and logging in with full access.

What Actually Works?

Modern endpoint security is built on layers — not PINs. Here’s what actually protects your users and estate:

UEFI Secure Boot to block bootkits.
TPM 2.0 with BitLocker.
Code Integrity + VBS + HVCI to enforce secure kernel operations.
Zero trust enforcement via Intune compliance and Conditional Access.
FIDO2 key-based auth to kill off password-based logins entirely.
Privileged Access Workstations (PAWs) for admins — no standing access.
TLS 1.2/1.3 and SSL everywhere for data in transit.

This is what actually holds up under scrutiny — even if your adversary isn't a petty thief, but a nation-state with time, tools, and talent.

Your posture should prevent logical access, not just physical.

Final Thoughts: If Intune Says You're Compliant, Are You Actually Secure?

That green tick might feel good. But it doesn’t mean you’re protected.

Compliance ≠ Protection
MDM ≠ Monitoring
Access ≠ Identity validation
Config ≠ Threat detection

Real security is layered, automated, and assumed breached until proven otherwise. If you’ve deployed Intune, great. Now back it with Conditional Access, EDR, automated patching, and identity threat detection.

Because when the breach happens — and it will — you don’t want to be the one saying “but we had Intune.”

Security