Have you ever thought your IT environment was safe simply because nobody knew how it was built? Renamed the admin account to something clever? Changed the default port? Hidden the server in a back room and hoped for the best? If so, you have been relying on one of the oldest and most dangerous illusions in cybersecurity: Security by Obscurity.
The uncomfortable truth is that obscurity is not a security strategy. It is a delay tactic — and a short one at that. This post breaks down why hiding your infrastructure is a losing game, and what real, layered security looks like in a modern Microsoft 365 environment.
The Myth of the Hidden Fortress
The concept of Security by Obscurity rests on the assumption that if an attacker does not know how your system works, they cannot break it. This sounds reasonable until you consider that attackers are patient, methodical, and increasingly automated. They do not need to know your architecture upfront — they will probe, enumerate, and discover it.
Kerckhoffs's Principle, formulated in 1883, states that a cryptographic system should be secure even if everything about the system, except the key, is public knowledge.
This principle has stood the test of time for a reason. The algorithms powering modern encryption — AES, RSA — are fully public. Their specifications are openly documented. Yet they remain secure because the security relies on the key, not on the secrecy of the algorithm. The moment you flip this logic and rely on secrecy as your primary defence, you have already lost.
Renaming your admin account to "SuperUser" is not hardening. Changing SSH from port 22 to port 2222 is not security. These are the IT equivalent of hiding a spare key under the doormat and calling it a vault.
The Zero Trust Bullshit Wall
Here is where it gets ironic. Many organisations, having recognised that obscurity does not work, swing to the opposite extreme. They pile on so many Conditional Access policies, MFA prompts, and password complexity requirements that the system becomes unusable for legitimate users — and they call the result Zero Trust.
It is not. Microsoft defines Zero Trust by three principles: verify explicitly (authenticate and authorise on all available signals), use least privilege access (just-in-time and just-enough access, risk-based adaptive policies), and assume breach (minimise the blast radius, segment access, verify end-to-end encryption). Password complexity requirements appear nowhere in that definition. Microsoft actively recommends against them. So what those organisations built is a stack of controls wearing the label, not the thing itself.
The result? Users write their 20-character, special-character-laden passwords on sticky notes and paste them to their monitors. Helpdesk tickets flood in. Workarounds proliferate. The Zero Trust Bullshit Wall has been built, and it is keeping out exactly the wrong people.
This is the KISS Principle failure in action: security rules so complex that they force users into behaviours that undermine the very security you were trying to enforce. A password policy that results in passwords on sticky notes is not a security policy — it is a liability. And this is not just my opinion. Microsoft's own operations guidance says that where a password policy uses complexity-based rules such as length, multiple character sets, or expiration, you should reconsider it in favour of Microsoft recommended practices and deploy Microsoft Entra password protection. Its guidance for cloud-only accounts is blunter still: the recommended setting is for passwords never to expire, and the Identity Secure Score lists "Do not expire passwords" as an improvement action.
Microsoft 365 provides the tools to avoid this trap. Passwordless authentication via Windows Hello for Business, FIDO2 security keys, and Microsoft Authenticator eliminates the password problem entirely. Conditional Access policies, when designed thoughtfully, enforce strong security without creating friction for legitimate users — and there is a documented way to design them that way. Create every new policy in report-only mode, evaluate its real impact in the Conditional Access insights workbook, then switch it on. That is the answer to the ticket storm, and it costs nothing but patience. The goal is not to build a wall — it is to build a gate that opens for the right people and stays shut for everyone else.
Building Real Defense in Depth
Defense in Depth is the antidote to both Security by Obscurity and the Zero Trust Bullshit Wall. The concept is straightforward: no single security control is sufficient on its own. Instead, you layer multiple overlapping controls so that if one fails, others remain in place.
In a Microsoft 365 environment, this layered approach maps naturally to the following stack:
| Layer | Control | Microsoft 365 Tool |
|---|---|---|
| Identity | Multi-Factor Authentication, Passwordless | Entra ID, Conditional Access |
| Device | Device compliance, patch management, EDR | Intune, Microsoft Defender for Endpoint |
| Network | Traffic filtering, segmentation | Microsoft Entra Internet Access and Private Access (Global Secure Access) for user-to-app traffic; Azure Firewall and network security groups for Azure workloads |
| Application | Vulnerability management, secure configuration, SaaS governance | Microsoft Defender Vulnerability Management, Microsoft Defender for Cloud Apps, Microsoft Secure Score |
| Data | Encryption, access controls, DLP | Microsoft Purview, Sensitivity Labels |
Two notes on that table, because both cells are commonly filled in with the wrong product. Microsoft Defender for Cloud Apps is a CASB: it discovers shadow IT, connects SaaS apps through their APIs, and applies session controls. It does not filter network traffic and does not segment networks, so it belongs in the Application row. And Microsoft Defender for Cloud is the posture and workload-protection product for Azure and multicloud infrastructure — it has no role in a Microsoft 365 application layer, and putting it there sends readers looking for a product they do not own.
The critical insight is that this stack eliminates single points of failure. If an attacker bypasses MFA through a phishing attack, a non-compliant device policy prevents them from accessing corporate resources. If they somehow get onto a compliant device, network controls and DLP policies limit what they can exfiltrate. Each layer buys time and reduces the blast radius of a breach.
Worth saying out loud, though: the real answer to MFA phishing is phishing-resistant MFA, not a second layer catching what the first one missed. The Identity Secure Score names "Ensure phishing-resistant MFA strength is required for Administrators" as an improvement action, and that is where to start. One prerequisite for the device layer that trips people up: without an Intune compliance policy in place and at least one compliant device, the Conditional Access policy that requires compliance will not behave the way you expect.
The Antidote to Privilege Creep
One of the most insidious threats in any organisation is not the external attacker — it is the internal user with too much access. This is the problem of Privilege Creep: over time, employees accumulate permissions from role changes, project assignments, and the ever-popular "just in case" access grants. Nobody ever removes the old access. Eventually, a single compromised account can do catastrophic damage.
The solution is a combination of two principles. Least Privilege means every user, service account, and application gets exactly the access required for their current role — nothing more. Separation of Duties means critical actions require a request from one person and approval from a separate, distinct person. The requester and the approver cannot be the same individual.
In Microsoft 365, Entra ID Privileged Identity Management (PIM) operationalises both of these principles. Administrators do not hold permanent privileged roles — they request elevation for a specific time window, with justification, and the access expires automatically. Access Reviews provide the recertification mechanism: on a regular cadence, managers and resource owners review who has access to what, and revoke anything that lacks a current business justification.
Check the licensing before you build a plan around this. PIM and Access Reviews are not part of a baseline Microsoft 365 subscription. Both need Microsoft Entra ID P2 or Microsoft Entra ID Governance, and you need a license for every user with an eligible or time-bound assignment, every approver, every user under review, and every reviewer — Microsoft's own worked example puts a 50-admin organisation at 53 licenses. If the license lapses, eligible assignments are removed and running access reviews end. If P2 is out of reach for you, say so and plan the fallback honestly: permanent role assignments on a hardened, separate set of admin accounts, plus manual recertification on a calendar.
Match the recertification cadence to the privilege. Annual is a reasonable floor for ordinary application access, but it is far too slow for privileged directory roles — Microsoft's own reference scenario runs monthly reviews of users assigned to administrator roles, and it names Global Administrator, Identity Governance Administrator, User Administrator, Application Administrator, Cloud Application Administrator and Privileged Role Administrator specifically. Review privileged roles monthly or quarterly, and everything else annually.
Running an access recertification campaign is not bureaucracy. It is the difference between a contained incident and a full-scale breach.
Secure by Design: Stop Treating Security as an Afterthought
The final principle worth addressing is one that applies not just to enterprise IT, but to every software project, every new deployment, and every configuration change: Secure by Design. Security cannot be bolted on at the end of a project. By the time a system reaches production, the cost of fixing a fundamental security flaw is an order of magnitude higher than addressing it at the design stage.
This means integrating security requirements from the very beginning of the development or deployment lifecycle. It means hardening default configurations before a system goes live and treating every new workload as a potential attack surface from day one. Hardening, to be clear, is not renaming things — that would be the same obscurity this post spent its first half dismantling. It is what Microsoft actually recommends and scores: protect and manage local admin passwords with Windows LAPS, use least-privileged administrative roles, designate more than one Global Administrator, block legacy authentication, and do not expire passwords. All five are named improvement actions in the Identity Secure Score. Applying least privilege to service accounts belongs on that list too. Renaming the built-in admin does not.
Microsoft provides the tooling to make this practical. Microsoft Secure Score gives you a measurable baseline and ranked recommended actions across Identity, Device, Apps and Data — allow 24 to 48 hours for a change to show up in the score, or you will think it did not work. Alongside it, Microsoft Defender Vulnerability Management flags misconfigurations before they become vulnerabilities. (If you also run Azure or multicloud workloads, Microsoft Defender for Cloud is the equivalent for that infrastructure — a different product for a different estate.) The work is not glamorous, but it is the foundation on which everything else rests.
Key Takeaways
- Security by Obscurity is not a strategy. Kerckhoffs's Principle has been telling us this for over a century.
- Overly complex security controls create workarounds that undermine security. Apply the KISS Principle.
- Defense in Depth eliminates single points of failure by layering Identity, Device, Network, Application, and Data controls.
- Privilege Creep is a silent threat. Entra ID PIM and regular Access Reviews are your countermeasures — both require Entra ID P2 or Entra ID Governance, licensed per eligible admin, approver and reviewer. Review privileged roles monthly or quarterly, not annually.
- Security must be built in from the start, not added at the end.
Security is not about hiding your infrastructure and hoping nobody looks. It is about building transparent, robust, and layered defences that hold even when — not if — someone comes looking. Microsoft 365 provides the tools. The question is whether you are using them.
References
- Auguste Kerckhoffs, La cryptographie militaire, Journal des sciences militaires, 1883.
- Microsoft, Zero Trust security model and framework, learn.microsoft.com.
- Microsoft, What is Privileged Identity Management?, learn.microsoft.com.
- NIST, Defense in Depth, NIST Special Publication 800-53.
