Case study — illustrative reference architecture
Zero-Trust Enterprise Access
An identity-first access architecture that removes implicit network trust for people and workloads.
Context
Scenario & business problem
Scenario
A hypothetical organization supports employees, administrators, contractors, SaaS platforms, cloud workloads, and remote users across managed and unmanaged devices.
Business problem
Access is granted by network location and long-lived credentials. Contractors keep entitlements after projects end, administrators hold standing privilege, and workload credentials are shared. The organization needs an access architecture where every request is authenticated, authorized, and evaluated against device and context signals.
Business drivers
- Remove implicit trust granted by network position
- Enforce least privilege for people and workloads
- Make contractor and leaver offboarding reliable
- Reduce standing administrative privilege
- Produce reviewable access evidence
Current-state challenges
- VPN access implies broad internal network reachability
- Administrators use permanently privileged personal accounts
- Service accounts share static credentials across environments
- No consolidated view of who can reach which system
- Leaver process depends on manual ticket completion
Who is affected
Stakeholders
Identity Team
One authoritative identity source and clean lifecycle events.
Security Engineering
Policy enforcement, session telemetry, break-glass governance.
Platform Engineering
Workload identity that removes shared static secrets.
Service Desk
Predictable access requests and fewer lockouts.
Business Unit Leads
Contractors productive quickly without permanent entitlements.
Analysis
Requirements, assumptions & constraints
Functional behaviour is separated from measurable quality attributes so that tradeoffs can be argued against numbers rather than opinions.
Functional requirements
- Single sign-on for internal applications and SaaS platforms
- Conditional access policies by user risk, device state, and resource sensitivity
- Time-bound elevation for administrative roles
- Automated provisioning and deprovisioning from HR and contractor sources
- Workload-to-workload authentication without shared static keys
- Illustrative quarterly access recertification workflow with an approver of record
Non-functional requirements
- Authentication decisions in under one second at the policy layer
- Identity provider availability objective of 99.95% with documented failure mode
- Authentication and authorization events forwarded to the SIEM for centralized monitoring and investigation
- Privileged sessions recorded and retained for 12 months
- Break-glass accounts usable without dependency on the policy layer
Assumptions
- A single workforce identity provider can be authoritative
- Managed devices report posture through an endpoint management platform
- SaaS platforms support standards-based federation and provisioning
Constraints
- Contractors use unmanaged devices and cannot install agents
- Two legacy applications support only header-based authentication
- Change freeze during quarter-end financial close
Guardrails
Architecture principles
Design
Target architecture
Components, trust zones, and the flows that cross their boundaries.
Trust flow — authentication, authorization, and device trust
Users and devices present identity and posture signals to the identity provider. A policy layer combines authentication result, device trust, and role to authorize each resource request. Administrative access takes a separate, elevated path. All planes emit telemetry to the SIEM.
Principals
Who or what is requesting accessEmployees
Managed devices, standard roles
Administrators
Separate admin identities, no daily-driver privilege
Contractors
Unmanaged devices, scoped and time-boxed access
Cloud workloads
Federated workload identities, no static keys
Device trust signals
Posture feeds the policy decisionManaged endpoints
Compliance, patch level, disk encryption
Unmanaged endpoints
Browser-isolated, download restrictions
Identity & policy layer
Authentication then authorizationIdentity provider
Authentication, MFA, phishing-resistant factors
Conditional access policy
Authorization by role, device, risk, sensitivity
Privileged access service
Just-in-time elevation, approval, session recording
Secrets & key management
Short-lived credentials for service-to-service calls
Protected resources
Enforcement at the resource edgeInternal applications
SSO, per-application entitlements
SaaS platforms
Federated, provisioned, deprovisioned automatically
Cloud resources
Role assumption with scoped, expiring sessions
Administrative plane
Reached only from privileged workstations
Assurance & governance
Evidence and lifecycleLogging / SIEM
Authentication, authorization, session events
Access reviews
Illustrative quarterly recertification with named approvers
Joiner / mover / leaver
Source-of-truth driven provisioning changes
Break-glass accounts
Sealed, alarmed on use, illustrative quarterly validation
Flows & boundaries
- Users Identity providerAuthentication with MFAAuthentication / authorization
- Devices Conditional access policyDevice posture signalControl & telemetry
- Identity provider Conditional access policyVerified identity + risk scoreAuthentication / authorization
- Conditional access policy Applications & SaaSAuthorization decision, scoped sessionAuthentication / authorization
- Administrators Privileged access serviceJust-in-time elevation requestControl & telemetry
- Privileged access service Administrative planeTime-bound, recorded sessionControl & telemetry
- Workloads Secrets & key managementWorkload identity exchanged for short-lived credentialAuthentication / authorization
- All planes Logging / SIEMAccess telemetry collected for centralized monitoring and investigationControl & telemetry
- Joiner / mover / leaver Identity providerLifecycle events drive entitlement changesControl & telemetry
Controls
Security, resilience & operational controls
Workforce identity
- Single identity source
- HR system is authoritative for employees; sponsor records for contractors.
- Multi-factor authentication
- Phishing-resistant factors for administrators and sensitive apps.
- Conditional access
- Policies combine role, device compliance, location anomaly, and risk.
Privileged access
- Administrative separation
- Distinct admin identities that cannot read email or browse freely.
- Just-in-time elevation
- Approval-gated, time-bound, fully logged with session capture.
- Break-glass governance
- Two sealed accounts, use raises a high-severity alert, illustrative quarterly break-glass validation with post-use review.
Workload identity
- Service-to-service authentication
- Federated workload identity in place of shared API keys.
- Short-lived credentials
- The target design uses short-lived workload credentials and avoids intentionally persisting long-lived shared service credentials to local disk.
- Scoped roles
- One role per service with explicit resource-level permissions.
Lifecycle & assurance
- Joiner / mover / leaver
- Automated grant, change, and revoke driven by source-of-truth events.
- Access reviews
- Illustrative quarterly access recertification with named approvers; unreviewed entitlements expire by default.
- Session monitoring
- Anomalous session behaviour raises detections in the SIEM.
Honesty
Tradeoff analysis
Every architectural gain is paid for somewhere. These are the bills.
| Choice | What it gains | What it costs |
|---|---|---|
| Stronger authentication and device checks | Materially reduces credential-theft and unmanaged-device risk. | Added user friction and more service-desk contact in early weeks. |
| Centralized identity provider | One place to enforce policy, review access, and revoke on exit. | Concentrated dependency; an identity outage blocks nearly everything. |
| Short session lifetimes | Shrinks the window in which a stolen session is useful. | More re-authentication prompts and interrupted long-running work. |
| Just-in-time privileged access | Removes standing privilege and produces an approval trail. | Slows emergency administrative response unless break-glass is well drilled. |
ADRs
Architecture decision records
Centralized identity provider as the primary control plane
Accepted- Context
- Access is currently granted by network position and per-application local accounts, leaving no consolidated view of entitlements.
- Decision
- Make one workforce identity provider authoritative for workforce authentication, with a policy layer evaluating authorization for applicable protected-resource requests.
- Alternatives considered
- Keep per-application authentication with a password manager
- Network-centric access via expanded VPN segmentation
- Federated multi-provider model per business unit
- Benefits
- One place to enforce MFA, review access, and revoke on exit
- Consistent telemetry for every authentication decision
- Enables conditional access based on device and risk signals
- Tradeoffs
- Concentrated dependency on a single platform
- Migration effort for legacy header-based applications
- Policy misconfiguration has broad blast radius
- Operational impact
- Identity availability becomes a top-tier dependency; policy changes require staged rollout and report-only testing.
Just-in-time privileged access vs standing administrative rights
Accepted- Context
- Administrators currently hold permanent privileged roles on their daily-use accounts, so any endpoint compromise is immediately a privileged compromise.
- Decision
- Introduce separate administrative identities with approval-gated, time-bound elevation and session recording; retain two governed break-glass accounts.
- Alternatives considered
- Standing admin rights with stronger monitoring
- Shared privileged accounts held in a vault
- Full separation with permanently privileged admin identities
- Benefits
- Removes standing privilege from everyday endpoints
- Creates an approval and session trail for sensitive work
- Limits the value of a stolen administrator session
- Tradeoffs
- Slower emergency response if elevation is unavailable
- Approval workflow adds process overhead
- Break-glass accounts need their own governance and testing
- Operational impact
- On-call procedures must include elevation steps; break-glass use is alarmed and reviewed after every activation.
Workload identity federation vs shared static service credentials
Accepted- Context
- Service-to-service calls use long-lived shared keys copied across environments, with no reliable rotation or attribution.
- Decision
- Use federated workload identities that exchange platform-issued tokens for short-lived, scoped credentials.
- Alternatives considered
- Long-lived keys with scheduled rotation
- Mutual TLS with a private certificate authority only
- Per-environment keys held in the secrets service
- Benefits
- Reduces reliance on long-lived shared service secrets stored in application images or hosts
- Workload-specific identities enable stronger attribution of authenticated service calls when supported by platform telemetry
- Scoped permissions per service instead of one shared key
- Tradeoffs
- Requires application changes and a credential-refresh path
- Debugging authentication failures is less obvious
- Depends on platform token issuance being healthy
- Operational impact
- Teams must instrument token-refresh failures; incident runbooks include identity-issuance troubleshooting.
Governance
Risks & mitigations
| ID | Scenario | Likelihood | Impact | Component | Mitigation | Residual | Owner |
|---|---|---|---|---|---|---|---|
| RSK-05 | Identity provider outage prevents workforce access to all federated applications. | Low | High | Identity provider | Documented degraded-access procedure, governed break-glass accounts, and illustrative quarterly drills. | Medium | Identity Team |
| RSK-06 | Conditional access policy misconfiguration locks out a business unit during rollout. | Medium | Medium | Policy / access layer | Report-only rollout, staged enforcement rings, and an emergency policy-revert runbook. | Low | Identity Team |
| RSK-07 | Contractor entitlements persist after project completion because sponsor records are not updated. | High | Medium | Access lifecycle | Time-boxed entitlements that expire by default, plus illustrative quarterly recertification with named approvers. | Low | Identity Team |
| RSK-08 | Break-glass account credentials are used without detection or post-use review. | Low | High | Privileged access | Sealed credentials, high-severity alert on any use, mandatory post-use review and rotation. | Low | Security Engineering |
| RSK-14 | Workload token issuance failure blocks service-to-service authentication across the platform. | Low | High | Workload identity | Credential caching with graceful expiry handling and issuance-health alerting. | Medium | Platform Engineering |
Sequencing
Reference implementation roadmap
These phases describe a reference implementation approach. They are not a record of a real production deployment.
- Phase 1
Discovery & Requirements
- Inventory applications, identities, and entitlements
- Classify resource sensitivity
- Map contractor and admin access paths
Exit criteria Agreed access model and policy targets.
- Phase 2
Foundation
- Consolidate to one identity provider
- Enable MFA baseline
- Connect SIEM ingestion for identity events
Exit criteria Single authoritative identity plane with telemetry.
- Phase 3
Migration / Implementation
- Federate applications and SaaS
- Roll out conditional access in report-only then enforce
- Introduce workload identities
Exit criteria Majority of access flows through policy enforcement.
- Phase 4
Security & Operational Hardening
- Remove standing admin roles
- Deploy privileged access service
- Retire shared service-account credentials
Exit criteria No permanent privileged entitlements outside break-glass.
- Phase 5
Validation
- Leaver revocation test
- Break-glass drill
- Access review cycle completed end to end
Exit criteria Evidence that entitlements match intent.
- Phase 6
Optimization
- Tune policies to cut false prompts
- Automate recurring access requests
- Reduce role sprawl
Exit criteria Lower friction at the same control strength.
Evidence
Validation approach
- Simulated leaver loses all access within the agreed window
- Conditional access blocks a non-compliant device from a sensitive app
- Privileged elevation produces an approval record and session log
- Break-glass use triggers an alert within minutes