Zero Trust Consultancy: Identity-Centric Access Architecture for Cloud and Hybrid Enterprises
This identity-centric Zero Trust architecture shows how a Zero Trust consultancy can translate business requirements into practical identity, access, device, data and monitoring controls across cloud and hybrid environments. The worked example uses a cloud-based consultancy that requires secure, seamless access to business applications, SharePoint-based client files, and sensitive internal systems across corporate devices, BYOD endpoints, internal users, external consultants, and client guests.
Executive Summary
This architecture enables a global consultancy workforce to access organisational resources, federated business applications, SharePoint client workspaces, and sensitive business systems using a centralised identity control plane. It supports both corporate devices and BYOD while reducing the risk of credential compromise, unmanaged endpoint exposure, stale access, and confidential data leakage.
The design centralises authentication through Microsoft Entra ID, uses Conditional Access to evaluate trust signals, applies RBAC and ABAC to govern access, and introduces JIT access for sensitive databases. External clients are governed through Entra B2B guest identities, allowing controlled collaboration without relying on unmanaged sharing links.
The intended outcome is a secure, auditable, and operationally usable identity architecture where access is continuously evaluated, sensitive data is protected proportionately, and leadership gains visibility into identity, access, and data-risk patterns.
What does a Zero Trust consultancy help an organisation do?
A Zero Trust consultancy helps turn Zero Trust principles into an operating architecture that reflects the organisation's users, applications, devices, data, third parties and risk profile. The work is not simply to add more authentication controls; it is to redesign how trust is established, how access is granted and how risky access is detected and removed.
Assess the current trust model
Identify where the organisation still relies on implicit trust, broad standing access, unmanaged devices, weak guest controls or inconsistent identity lifecycle processes.
Design the target architecture
Define how identity, MFA, Conditional Access, device posture, RBAC, ABAC, PIM/JIT, data controls and monitoring should work together.
Prioritise implementation
Sequence improvements so the highest-risk trust assumptions are reduced first without creating unnecessary operational friction.
Build governance and assurance
Define ownership, review cycles, audit evidence, access metrics and response actions so the architecture remains effective after implementation.
Typical Zero Trust consultancy outputs
- current-state and target-state Zero Trust architecture
- identity and access control design
- Conditional Access and trust-signal decision model
- privileged access and JIT/PIM design
- guest and third-party access governance
- device and BYOD access strategy
- control, monitoring and response architecture
- implementation roadmap, decision log and assurance measures
Business Context
Business Objective
The consultancy needs to enable seamless workforce and client access to organisational resources while reducing confidential data leakage, preserving data integrity, and maintaining availability of client and proprietary files.
Business Failure
Business failure occurs where confidentiality, integrity, or availability is compromised: client files become unavailable, sensitive files are leaked, proprietary knowledge is exposed, or access failures prevent consultants from delivering services.
Actors
Admins Consultants External Consultants Clients Data Owners Security Team
Protected Assets
| Asset | Risk if Compromised |
|---|---|
| Employee personal data | GDPR exposure, employee distress, regulatory consequences. |
| Client files | Operational disruption, reputational damage, loss of client trust. |
| Intellectual property | Loss of competitive advantage, revenue impact, commercial exposure. |
| Sensitive company files | Attack enablement through leakage of security reports, vulnerabilities, or internal designs. |
| Top secret database | High-impact breach requiring restricted, approved, time-bound access only. |
Layer 1–5 Architecture Views
Use the buttons below to move through the architecture from business context to risk assurance.
Layer 1 — Business View
Purpose: Enable secure client delivery while protecting confidentiality, integrity, and availability.
Actors: Admins, consultants, external consultants, clients, data owners, security operations.
Critical assets: Client files, IP, sensitive company data, employee PII, sensitive database.
↓
↓
Layer 2 — Identity & Access View
Identity: Entra ID for workforce identities; Entra B2B guest identities for clients.
Access model: RBAC for baseline access, ABAC for contextual access, PIM/JIT for sensitive database access.
Trust signals: MFA, sign-in risk, device compliance, location, IP reputation, session behaviour, file sensitivity.
↓
↓
↓
Layer 3 — Technical Architecture View
Core systems: Entra ID, SharePoint, Intune, Sentinel, federated business applications, sensitive database.
Protocols: OIDC where supported, SAML where required, SCIM for lifecycle provisioning, HTTPS/TLS for access.
Hosting: Cloud-hosted Microsoft 365 and SaaS estate, with endpoint posture evaluated through device management.
↓
↓
↓
Layer 4 — Security Controls View
Prevent: MFA, Conditional Access, sensitivity labels, JIT access, browser-only restrictions.
Detect: Entra risk detections, SharePoint audit logs, endpoint telemetry, Sentinel correlation.
Respond: Session revocation, forced reauthentication, account suspension, entitlement removal.
Recover: Break-glass, file versioning, account recovery, access revalidation.
↓
↓
↓
Layer 5 — Risk & Assurance View
Residual risks: External identity compromise, token theft, unmanaged endpoint exposure, access drift.
Assurance: Quarterly policy review, monthly guest review, KPI-driven control validation.
Audit: End-to-end evidence from identity assertion to resource access retained centrally.
↓
↓
↓
Identity, Access and Trust Model
| Area | Architecture Position |
|---|---|
| Identity Flow | Internal consultants use Entra identities; clients use Entra B2B guest identities. Authentication is performed through Entra ID using phishing-resistant MFA or Windows Hello where supported. |
| Access Model | RBAC provides baseline access; ABAC refines access by project, client, file sensitivity, location, sign-in risk, and device posture. Sensitive database access uses PIM/JIT. |
| Trust Model | Trust is established through valid identity, strong authentication, acceptable sign-in risk, device posture, entitlement, and session behaviour. Trust is continuously evaluated and degraded when risk increases. |
| Trust Boundaries | Risk changes at identity assertion, guest federation, device posture evaluation, session establishment, file download, sharing actions, and cross-tenant collaboration. |
Threat Model
The dominant threat model is exploitation of valid trust relationships rather than traditional perimeter compromise. The highest-risk points are external identity federation into internal resources and sensitive file content leaving SaaS storage for unmanaged endpoints.
| Threat Area | Threat Analysis |
|---|---|
| Major attack paths | Credential compromise, token theft, unmanaged BYOD compromise, guest misuse, malicious sharing, API abuse, stale entitlements. |
| Boundary threats | Device malware, hostile networks, MFA fatigue, token replay, federation dependency risk, data exfiltration at download boundary. |
| Abuse cases | Guest account accessing excess files, internal oversharing, OAuth consent abuse, stale access after project closure. |
| Insider risks | Intentional export, broad permission abuse, access retention after business need ends, misconfigured guest access. |
| Data exfiltration paths | Download, sync, email forwarding, external links, API extraction, copy/paste, screenshot capture, bulk harvesting. |
Control Strategy
| Control Type | Controls |
|---|---|
| Preventive | Entra ID, MFA/passwordless, Conditional Access, RBAC/ABAC, guest governance, Intune compliance, sensitivity labels, browser-only access, SCIM lifecycle automation. |
| Detective | Entra Identity Protection, SharePoint/OneDrive audit logs, endpoint telemetry, behavioural analytics, impossible travel, token misuse detection, Sentinel correlation. |
| Response | Session revocation, forced reauthentication, step-up authentication, temporary restriction, guest revocation, account suspension, entitlement removal, incident generation. |
| Recovery | Break-glass access, account recovery, entitlement revalidation, controlled token reissuance, file versioning, emergency secure collaboration paths. |
Architecture Decision Log
| Decision | Rationale | Trade-Off | Residual Risk |
|---|---|---|---|
| Use Entra ID as identity control plane | Native Microsoft 365 integration, Conditional Access, B2B, device trust, auditability. | Microsoft dependency concentration. | IdP compromise or misconfiguration. |
| Use OIDC where supported | Modern token-based authentication suited to SaaS and APIs. | SAML may remain for legacy apps. | Token theft, redirect URI weakness. |
| Use B2B guest identities | Controlled collaboration without unmanaged sharing links. | Guest lifecycle overhead. | Client identity compromise. |
Monitoring, Response and Recovery
Detection Architecture
Authentication events, Conditional Access decisions, guest sign-ins, token activity, device posture, file access, download behaviour, sharing events, entitlement changes, and endpoint telemetry are aggregated into Sentinel for correlation.
Incident Response Model
Risk increases trigger proportional trust degradation: step-up authentication, session restriction, download blocking, forced reauthentication, access removal, or account suspension.
Recovery Model
Access is restored only after identity assurance is revalidated, entitlements are confirmed, risk is resolved, and new trusted sessions are issued.
Break-Glass
Break-glass applies where the identity control plane is unavailable, misconfigured, compromised, or inaccessible due to Conditional Access lockout, federation failure, or administrative privilege loss.
When does an organisation need Zero Trust consultancy support?
Zero Trust consultancy support is most useful when the organisation understands the principle but needs to turn it into architecture, policy and implementation decisions across multiple technology and business domains.
Cloud or hybrid transformation
Access patterns have moved beyond a trusted corporate network and the organisation needs identity-led controls across SaaS, cloud and hybrid resources.
Identity and access complexity
Multiple roles, guests, contractors, privileged users and applications have created access drift or inconsistent control.
Zero Trust roadmap needed
The organisation needs to prioritise what to change first rather than attempting a broad transformation without a sequenced architecture.
Assurance and governance gaps
Controls exist, but ownership, evidence, monitoring, review cadence or risk-based decision logic is unclear.
Risk, Assurance, Audit and Governance
Risk Treatment Register
| Treatment | Application |
|---|---|
| Accepted | Controlled BYOD usage where full endpoint control is impractical. |
| Mitigated | Credential theft, session hijacking, guest sprawl, and access drift through Conditional Access, lifecycle controls, and monitoring. |
| Transferred | Cloud platform availability and underlying SaaS resilience to Microsoft’s service model. |
| Avoided | Standing privileged access, unrestricted unmanaged-device downloads, and unmanaged external collaboration. |
Assurance Model
Controls are validated through an evidence-based review cycle using KPIs including guest access review completion, dormant guest accounts, risky sign-ins, MFA success rate, unmanaged-device access rate, file download anomalies, entitlement drift, deprovisioning timeliness, and detection-to-response time.
Audit Model
The audit trail should reconstruct the full access journey from identity assertion to resource access: authentication event, token issuance, MFA outcome, Conditional Access decision, guest invitation, entitlement change, file access, file sharing, file download, device compliance state, and response action.
Governance Model
Data owners review access to the resources they own. Identity administrators oversee guest lifecycle, access policy, and entitlement hygiene. Security operations own detection and anomaly review. Review cycles are risk-based, with guest access reviewed monthly and identity policies reviewed at least quarterly.
Trade-Off Register
| Trade-Off | Security Benefit | Business / Operational Cost |
|---|---|---|
| BYOD permitted with restrictions | Maintains workforce flexibility while enforcing conditional access. | Lower endpoint assurance than fully managed devices. |
| Browser-only access for unmanaged devices | Reduces local data persistence and uncontrolled sync. | Reduces offline productivity and convenience. |
| Guest identities over anonymous links | Improves auditability, entitlement control, and revocation. | Requires guest lifecycle governance. |
| Centralised Entra control plane | Improves consistency, policy enforcement, and visibility. | Concentrates dependency on Microsoft identity availability. |
| JIT access for sensitive database | Removes standing privilege and improves accountability. | Introduces approval friction for occasional access. |
Future State / Version 2
| Question | Architecture Evolution |
|---|---|
| What would improve next? | Move towards phishing-resistant authentication as the default, mature sensitivity labelling, strengthen external guest access governance, and introduce more granular access policies for client workspaces and sensitive databases. |
| What would be automated next? | Automate guest access expiry, access review reminders, entitlement removal at project closure, Sentinel incident creation, ServiceNow case routing, high-risk session revocation, and periodic reporting to leadership. |
| What would be strengthened next? | Strengthen device compliance signals, endpoint detection coverage, OAuth app governance, privileged access workflows, database activity monitoring, break-glass monitoring, and detection rules for identity-to-data attack chains. |
| What would be removed next? | Remove application-local passwords, long-lived standing access to sensitive systems, unmanaged external sharing links, stale guest accounts, persistent project access after closure, and broad default permissions across client file repositories. |
Zero Trust consultancy FAQs
What does a Zero Trust consultancy do?
A Zero Trust consultancy assesses where an organisation relies on implicit trust, designs a target-state architecture and helps define the identity, device, access, data, monitoring and governance controls needed to move toward continuously evaluated access.
What is Zero Trust identity and access management?
It is the practice of treating identity as the central control and continuously evaluating trust signals—rather than assuming a perimeter—to permit or restrict access to resources.
Is Zero Trust the same as Conditional Access?
No. Conditional Access is one enforcement mechanism within a broader Zero Trust architecture. Zero Trust also includes identity governance, least privilege, device trust, privileged access, data controls, monitoring, response and assurance.
How does Conditional Access fit into Zero Trust?
Conditional Access encodes trust signals into policy, such as device posture, location, sign-in risk and authentication strength, so access decisions are made in context at authentication and during the session.
When should a consultancy apply JIT / PIM?
Apply JIT/PIM for high-impact or sensitive resources where standing access would create unacceptable exposure. Use approval and justification workflows to preserve accountability.
What should a Zero Trust roadmap include?
A practical roadmap should identify current trust assumptions, prioritise high-risk access paths, define target controls, sequence implementation dependencies and set measurable assurance criteria for identity, devices, privileged access, data and monitoring.
Can Zero Trust support BYOD and external consultants?
Yes. The model can apply different trust requirements to managed and unmanaged devices, external identities and guest users, with proportionate restrictions such as browser-only access, stronger authentication, reduced download capability or time-bound entitlements.