Identity-Centric Zero Trust Access Architecture
A reference security architecture for a cloud-based consultancy that needs secure access to business applications, SharePoint client files, and sensitive internal systems across corporate devices, BYOD endpoints, internal users, external consultants, and client guests.
Executive Summary
This reference 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.
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, and loss of client trust. |
| Intellectual property | Loss of competitive advantage, revenue impact, and 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. |
Problem Statement
The previous identity model introduced avoidable operational friction and security exposure.
- Multiple applications required separate passwords, encouraging weak or reused credentials.
- Corporate and BYOD devices had inconsistent access treatment.
- Joiners, movers, and leavers were managed manually across applications.
- Sensitive database access was manually provisioned and not consistently time-bound.
- Leadership lacked visibility into identity lifecycle risks and access control weaknesses.
Architecture Objectives
| Objective | Architecture Intent |
|---|---|
| Centralised access | Users access federated business applications through Entra ID with strong authentication. |
| Sensitive access control | Access to sensitive databases uses approved, justified, time-bound JIT workflows. |
| Lifecycle alignment | Identity-dependent systems synchronise to a single operational identity control plane. |
| Risk visibility | Anomalous behaviour is monitored, correlated, and escalated through Sentinel. |
| BYOD governance | BYOD remains usable but subject to Conditional Access, device posture checks, and download restrictions. |
Scope and Assumptions
Users in Scope
Consultants Admins Clients External Consultants
Systems in Scope
Microsoft Entra ID Client External IdP Microsoft SharePoint Microsoft Intune Microsoft Sentinel Corporate + BYOD Devices Federated Business Applications Sensitive Business Systems
Trust Assumptions
It is assumed that consultancy and client identities are governed by their respective identity providers, that authentication signals are reliable, and that device posture data reflects the current security state of the endpoint.
Dependencies
The success of the design depends on the availability and integrity of Microsoft Entra ID, SharePoint, device compliance integrations, lifecycle provisioning mechanisms, Microsoft Sentinel telemetry ingestion, and federated trust with external client identity providers.
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. |
| Permit BYOD under restrictions | Supports operational agility while applying risk-aware controls. | Lower endpoint assurance. | Post-download exposure. |
| Browser-only for unmanaged devices | Reduces local persistence and uncontrolled sync. | Reduced offline usability. | Screenshot/copy risk. |
| Centralised SCIM lifecycle | Reduces access drift and improves deprovisioning timeliness. | Requires downstream support and sync health. | Provisioning failure or delay. |
| Sentinel as central monitoring | Correlates identity, device, and file activity for detection. | Log volume cost and tuning burden. | Detection gaps if telemetry is incomplete. |
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.
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. |
What This Demonstrates
This architecture demonstrates the ability to design identity-first security architecture that connects business risk, workforce enablement, guest collaboration, Conditional Access, lifecycle governance, detection, response, and auditability into a coherent operating model.
It shows practical security architecture thinking: not just drawing systems, but explaining how trust is established, how it degrades, where controls are enforced, what residual risks remain, and how the design can mature over time.