What hundreds of Microsoft 365 deployments have taught me about cybersecurity
I’ve spent more than 20 years running IT and security for organizations across California and around the country. Over that time, my team has taken over, deployed and cleaned up Microsoft 365 environments for law firms, commercial real estate companies, manufacturers, healthcare practices and schools.
I’ve spent more than 20 years running IT and security for organizations across California and around the country. Over that time, my team has taken over, deployed and cleaned up Microsoft 365 environments for law firms, commercial real estate companies, manufacturers, healthcare practices and schools.
After working with that many tenants, the biggest takeaway is simple: most Microsoft 365 security problems aren’t especially sophisticated. Usually, a control was never turned on, only covered part of the organization, or somebody made an exception years ago to keep something working and it was never revisited. Microsoft gives organizations a lot to work with. More often than not, the problem is how the environment was configured and maintained, not a lack of security tools.
These are the issues we run into most often and the areas I’d look at first.
Most environments are still running on their original settings
When we first assess a tenant, we often find that nobody has really gone back through the security settings since it was originally set up. MFA may cover some users but not everybody. Legacy authentication is still allowed. There are too many global administrators. Nobody is quite sure when audit logging was last reviewed.
Last year we took over a 45-person medical practice that had been on Microsoft 365 for almost a decade. We found nine global administrator accounts, including two belonging to employees who had left years earlier. MFA was enabled, but only for the physicians. The front desk and billing staff, who handled the most patient data, had none.
In context
- Topic: Ciberseguridad — Riesgo, identidad, respuesta a incidentes y cumplimiento.
- Source: CIO
- Published: 15/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
In security the story is rarely the attack. It is the time between the intrusion and somebody noticing. That number says more about an organisation than any certificate hanging on the reception wall.
My way of reading these cases is to ask what failed in the process, not what failed in the machine. Behind nearly every incident there is a reasonable decision taken under pressure: granting a permission to unblock somebody, postponing an update because it was month-end. That is where the lesson lives.
What usually goes wrong
What I see fail most is the backup. It is configured, it runs every night, nobody checks it. The day you need to restore, it turns out it had been failing silently for four months, or that everything was backed up except exactly what was needed. A backup never restored is an assumption.
What to watch
- How it was communicated to customers and regulators, which is where reputational cost is decided.
- Whether third parties or suppliers were in the chain, because the perimeter now includes partners.
- How long it took to detect, usually the most revealing metric in the whole case.
How I read this entry
I would use it for a conversation with the board, not with the technical team. The question you must be able to answer there is how long the business can operate without its systems and what each day of that outage costs. With that number, the security budget gets discussed differently.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
