Distributed IT Architecture: 7 Critical Decisions Made by Default

Most distributed IT architecture is never designed. It accumulates. A tenant gets created, people are added, an app asks for permission and someone clicks Accept, and eighteen months later the shape of the thing is whatever the product defaults happened to be on the days those decisions were not made.

That is not a criticism of anyone. Defaults exist because software has to do something when nobody has said otherwise, and most of them are reasonable starting points. The problem is narrower and more specific: a handful of those defaults are load-bearing. They decide who can reach your data, how far back you can look when something goes wrong, and whether you own a policy engine at all. When a business had one office and one network, several of them barely mattered. Distributed work moved them to the centre.

What follows is seven decisions that a distributed business either makes deliberately or inherits. Each one is drawn from the vendor’s or standards body’s own published documentation rather than from received wisdom, and each names the default so you can check yours against it.

1. Where trust comes from

The oldest assumption in corporate IT is that being on the network means something. It is the assumption behind the office LAN, the site-to-site VPN and the phrase “internal application”. It is also the one that NIST SP 800-207, the zero trust architecture publication finalised in August 2020, sets out to remove. Its formulation is worth reading literally: a zero trust architecture “assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet)”.

Note what that does not say. It does not say the network is irrelevant, or that VPNs are forbidden. It says location is not sufficient grounds for trust on its own. NIST puts the consequence plainly elsewhere in the same document: “network location is no longer seen as the prime component to the security posture of the resource”.

The practical failure is not that firms disagree with this. It is that they half-implement it. The staff work from anywhere, so the VPN was extended until everyone could reach everything, and the implicit trust that used to be bounded by a building is now bounded by nothing. The architecture did not move away from network-based trust. It kept network-based trust and removed the walls.

2. Whether you own a policy engine at all

If trust is not coming from location, something has to decide each request on its merits. In the Microsoft stack that something is Conditional Access, which Microsoft describes in its own documentation as “Microsoft’s Zero Trust policy engine” — it takes signals (user, device state, application, IP location, real-time risk) and returns a decision (block, or grant subject to conditions such as multifactor authentication or a compliant device).

Here is the part that decides whether the rest of this article is even available to you: Conditional Access requires Microsoft Entra ID P1. Below that licence there is no policy engine — not a weaker one, none. Microsoft 365 Business Premium includes it, which is one of several reasons that plan is better value than its price suggests; we worked through the licensing comparison separately. Risk-based policies need Entra ID P2.

Two details from the same page are easy to miss and both matter for design. Conditional Access is “enforced after first-factor authentication is completed”, so it is an authorisation control, not a front door. And when the licences lapse, existing policies are not deleted — you can view and delete them but not update them, which is a strange and quiet failure mode to discover during an incident.

3. Who is allowed to hand out access to your data

This is the default that surprises people most, and it is stated flatly in Microsoft’s user consent documentation: “By default, all users are allowed to consent to applications for permissions that don’t require administrator consent.”

In practice that means any employee can grant a third-party application ongoing access to their mailbox, and the grant survives their password changes and their MFA. Microsoft’s own recommendation is to narrow it: “we recommend that you allow user consent only for applications that have been published by a verified publisher”, which is the built-in microsoft-user-default-low policy.

The architectural sting is in the last paragraph of that page. Changing the setting “only affect[s] future consent operations” — “[e]xisting consent grants remain unchanged, and users continue to have access based on the permissions previously granted”. So tightening the policy does nothing about what has already been granted. That has to be a separate review, and in a distributed business that has been running for a few years it is rarely a short list.

4. How far back you can look

Every distributed IT architecture eventually has a bad week, and the question that decides how bad is how much history you kept. Microsoft Purview Audit (Standard) retains audit records for 180 days — raised from 90, but only for records generated on or after 17 October 2023.

Audit (Premium) keeps Entra ID, Exchange, OneDrive and SharePoint records for a year by default, everything else for 180 days, and can be extended to ten years with a per-user add-on. One line in that documentation is worth internalising before you rely on it: records generated by non-user entities — service principals, system events, application activity — are retained for a fixed one year, “isn’t configurable and custom audit log retention policies don’t apply”. The activity of the integrations you are least likely to be watching is the activity you have least control over retaining.

Six months sounds generous until you compare it with how long intrusions actually go unnoticed. The decision is not “is 180 days a long time” but “is 180 days longer than our realistic detection gap”. If you cannot answer that, the retention setting is not the first problem.

5. What a managed device means here

Conditional Access can require a device be marked compliant or Entra hybrid joined. That is only meaningful if something is establishing compliance, which means device management has to exist before the policy referencing it can do any work. Firms regularly write the policy first, discover it would lock out half the company, and set it to report-only indefinitely.

The complication a distributed IT architecture adds is that the fleet is genuinely mixed: company laptops, a contractor’s own machine, a phone that only ever touches Teams. A single compliant-device rule across all of that either blocks legitimate work or gets scoped so narrowly it protects nothing. The workable pattern is to decide per resource rather than per person — the finance system and the tenant admin portals demand a managed device, chat and calendar do not — which is the per-resource thinking NIST describes when it says the focus moves to protecting individual resources rather than network segments.

6. Where the data actually came to rest

Ask where the data in a distributed IT architecture lives and the honest answer is usually a list nobody has ever written down: the tenant, two or three SaaS products bought by different departments, a file share somebody kept, and whatever sits in the integrations wiring those together. Each of those is a place data can be read from, and each has its own access model that has to be reasoned about separately.

This is where the third-party exposure documented in the 2026 Verizon DBIR becomes concrete rather than abstract — third parties were involved in 48% of breaches, and the mechanism is very often an integration granted broad access once and never revisited. We covered the access model to insist on for external parties in more detail; the architectural point here is narrower. An integration is a permanent authenticated user of your data with no line manager and no leaving date.

7. Whether any of it was written down

The six decisions above are all recoverable. Someone can read the current settings out of the tenant in an afternoon. What is not recoverable is why — whether the consent policy is loose because somebody weighed it and accepted the risk, or because nobody ever opened the page.

That distinction is the entire difference between a distributed IT architecture and a collection of settings. The settings tell you the state. Only the record tells you which parts were chosen, which were inherited, and therefore which ones are safe to change. A business that cannot tell those apart is not able to make the next decision cheaply, because every change starts with an archaeology exercise.

This is also the least glamorous thing on the list and the first to be cut. It is worth defending precisely because it is what makes the other six maintainable rather than merely correct on the day they were set.

Where to start on a distributed IT architecture you inherited

Do not begin with a redesign. Begin with an inventory of the seven defaults above as they currently stand in your tenant, because most of them are readable in an hour and the answers tend to reorder the priorities on their own. The consent grant list and the audit retention setting are usually the two that change the conversation.

Then decide, explicitly, which of them you are accepting and which you are changing — and write down both. A distributed IT architecture is not really a diagram. It is the set of decisions you can still justify a year later, which is why the documentation item is on the list at all.

Certificates are one of these defaults, and the deadline on them is already published. The maximum life of a public TLS certificate fell to 200 days in March 2026 and reaches 100 in March 2027, which turns renewal from an annual errand into a standing process — our note on TLS certificate lifetimes has the dates. A distributed IT architecture spreads those certificates across more edges than anyone has written down, which is the actual problem rather than the arithmetic.

If you want that done as a piece of work rather than a reading exercise, our IT architecture and design service is built around exactly this: establish the current state, decide what changes, and leave you the written record. The related cybersecurity risk management work picks up where the identity and consent decisions lead.