ZERO TRUST IDENTITY, DEVICE, AND PRIVILEGED ACCESS FRAMEWORK A free template — pick the point on each control spectrum that matches your organization's risk profile, not someone else's reference architecture. Written by Adam Clifford (adam@cliffords.net) — adapted from a framework built and run in production across several organizations. Free to use, adapt, and redistribute. No attribution required, though I'd love to hear how you used it. -------------------------------------------------------------------- HOW TO USE THIS TEMPLATE -------------------------------------------------------------------- This is a working template, not a reference architecture. The shape of the architecture is what matters; the specifics will look different in your tenant. 1. Identify your risk profile using the self-assessment below. Most organizations land on Profile 2 (Standard). 2. Read each control area, review the spectrum of implementation options, and pick the point that matches your profile. The recommendations are conservative — start where indicated and step up over time if your profile shifts. 3. Replace every bracketed placeholder (for example, [Organization Name], [SIEM Platform], [DNS Filter Vendor]) with values for your environment. Delete control areas that do not apply. Authority and applicability: once adopted, this framework should be authoritative for the organization's identity, device, and privileged access controls, and should supersede prior administrative and access guidance. -------------------------------------------------------------------- DEFINING YOUR RISK PROFILE -------------------------------------------------------------------- Four organizational risk profiles. Each reflects a coherent combination of regulatory burden, data sensitivity, attacker interest, financial scale, and identity team maturity. Pick the profile that matches your organization today, not the one you aspire to. If your answers span multiple profiles, default to the higher one — security debt is harder to pay back than it is to take on. Profile 1 — Foundational Small organizations (typically under 200 employees), low regulatory burden, baseline threat exposure. Goal: get the table stakes in place without chasing enterprise-grade controls. Profile 2 — Standard Mid-market organizations (typically 200-3,000 employees), mainstream industry, typical threat exposure. Goal: implement the full architecture pragmatically. Profile 3 — Enhanced Regulated industries, organizations with high attacker interest, or larger organizations (3,000+ employees). Goal: full architecture with hardened controls and a workload identity program. Profile 4 — Maximum Defense industrial base, critical infrastructure operators, organizations handling classified or controlled-unclassified information. Goal: maximum assurance; hardware-anchored, air-gapped where feasible. Self-assessment dimensions: - Regulatory burden: none/general -> sector-specific -> heavy (HIPAA/PCI/SOX/FedRAMP Moderate) -> classified/CMMC L3/FedRAMP High - Data sensitivity: low business data -> customer PII/contracts -> regulated PII/PHI/financial -> classified/CUI - Attacker interest: opportunistic -> opportunistic/targeted -> persistent/targeted -> nation-state - Annual revenue/budget: under $50M -> $50M-$1B -> $1B+ or public sector strategic -> strategic national-security scale - IT/security maturity: one IT generalist -> IT team with partial security focus -> dedicated security team -> full SOC and threat hunting -------------------------------------------------------------------- QUICK-REFERENCE SPECTRUM MATRIX -------------------------------------------------------------------- Every control area at a glance. Pick your profile's column. Admin account tiering P1: Two tiers (Green/Red) P2: Full Green/Yellow/Red with prefixed naming P3: + a dedicated tier for control-plane ownership accounts P4: + hardware-key-bound dedicated identity store Authentication P1: TOTP/push minimum; FIDO2 for Global Admin P2: Phishing-resistant for Red tier; passkeys for the workforce P3: Phishing-resistant for all admin tiers P4: FIDO2/hardware key only, across the board Privileged Access Workstation P1: Separate accounts on a hardened endpoint P2: Virtualized PAW (cloud-hosted VDI) P3: Cloud PC or dedicated physical PAW P4: Dedicated or air-gapped physical PAW Just-in-time elevation P1: JIT-eligible for Global Admin only P2: JIT-eligible except for read-mostly Green roles P3: JIT-eligible default; always-on must be justified P4: JIT-eligible + approver workflow + under-4-hour windows Authentication Contexts / Protected Actions P1: One context covering Conditional Access policy changes P2: Full Protected Actions list mapped P3: Multiple contexts (Red, Workload, Cross-Tenant) P4: + per-action contexts with approver step-up Risk-based access P1: Sign-in risk if available P2: Sign-in + user risk, medium thresholds P3: Strict thresholds, automated remediation P4: Custom risk integrations from SIEM/SOAR Device hardening P1: Audit-mode baseline; encryption + supported OS enforced P2: Strict baseline + compliance enforced P3: + full OS coverage + mobile app management P4: + hardware attestation; device-bound credentials only Emergency access P1: Two cloud-only break-glass accounts P2: + certificate-based app registration P3: + hardware-security-module-backed certs + credential split P4: + hardware-key-bound; offline air-gapped recovery Access review cadence P1: Annual review of the Red tier P2: 90-day Red / 6-month Green / 12-month Yellow P3: 60-day Red / 90-day Green / 6-month Yellow P4: 30-day Red / 60-day Green / 90-day Yellow Workload identity governance P1: App consent governance P2: + quarterly app permission reviews P3: + app authentication policies; cert-only for high-priv apps P4: + managed identities default; approval workflow Detection / SOC coverage P1: Built-in directory audit alerts on Protected Actions P2: + SIEM ingestion of directory and device management audit logs P3: + identity threat detection + managed detection and response P4: + custom detections + 24x7 SOC + threat hunting -------------------------------------------------------------------- PURPOSE -------------------------------------------------------------------- This document defines a holistic Zero Trust identity, device, and privileged access framework for [Organization Name]. It combines: - Tiered administrative accounts (Green / Yellow / Red) - Conditional Access - Authentication strengths (phishing-resistant MFA) - Just-in-time privileged elevation - Privileged Access Workstations (PAWs) - Protected Actions and Authentication Contexts - Continuous Access Evaluation - Risk-based access controls (user risk and sign-in risk) - Self-service password reset and password protection - Endpoint hardening and compliance baselines - Layered emergency access and recovery - Ongoing access governance and review The goal is to maximize identity assurance and blast-radius reduction while minimizing administrator fatigue by applying friction only when risk justifies it. This document governs both administrative access and standard workforce user access. -------------------------------------------------------------------- DESIGN PRINCIPLES (profile-agnostic — implementation depth changes with profile; the principles do not) -------------------------------------------------------------------- - Passwordless for all interactive admin accounts (FIDO2/passkeys). Adjust the timeline by profile; the destination is the same. - All admin access requires managed and compliant devices. - No standing privilege for high-impact roles. JIT-eligible is the default; always-on must earn its place. - PAW is required for control-plane and data-exposure actions, not for routine admin work. - Authentication Contexts protect actions, not just roles. - Continuous Access Evaluation is relied on instead of aggressive reauthentication. - Session reuse is allowed where environment trust is already established. - Protected Actions always override tier-based defaults. - Emergency access is layered, intentional, and tightly controlled. - Privileged access is periodically reviewed and re-approved. Cadence varies by profile. -------------------------------------------------------------------- KEY CONCEPTS -------------------------------------------------------------------- Continuous Access Evaluation (CAE) Re-evaluates access decisions in near real time after a session is already established, rather than relying on short token lifetimes or frequent reauthentication. Triggers: password reset/disablement, risk level changes, Conditional Access policy changes, network location changes. Enable tenant-wide; it applies universally across all profiles and is foundational to reducing MFA fatigue while maintaining strong security. Authentication Contexts Step-up authentication at the moment of risk, rather than globally at sign-in. Bind higher-assurance requirements — fresh phishing-resistant authentication, PAW usage, JIT elevation — to specific actions such as role elevation or control-plane operations. Risky Users An identity believed compromised based on aggregated signals over time: leaked credentials found on the internet, repeated anomalous sign-in behavior, malware-linked activity, correlated risky sign-ins across locations/devices. Medium or high risk requires remediation (typically password reset or stronger auth) before access is restored. Risky Sign-Ins A potentially malicious authentication attempt evaluated per event: anonymous IP addresses, impossible/atypical travel, unfamiliar device or location, known malicious infrastructure. Mitigate via step-up authentication or blocking, depending on severity. Why risk-based access matters Security controls that adapt dynamically to threat conditions instead of treating all sign-ins equally: stop account takeover quickly, reduce unnecessary MFA prompts for low-risk users, work with CAE to revoke sessions when risk changes, and provide a critical defense against phishing, MFA fatigue, and token replay. -------------------------------------------------------------------- ACCOUNT TYPES (naming is illustrative — replace prefixes with your organization's scheme; the category model is the load-bearing part) -------------------------------------------------------------------- Administrative Accounts (e.g. ADM_) - Interactive, human-operated admin accounts - No productivity access (email, chat, file storage) - Scoped into Green or Red tiers - Passwordless at Profile 2 and above; phishing-resistant required for Red at every profile Identity Management Accounts (e.g. IDM_) - Control-plane ownership accounts — do not hold admin access directly; instead they own the groups that admin roles are assigned to, so privileged groups can only be managed by an account holding group ownership or a directory-level identity admin role - Passwordless only; always Red tier; JIT-eligible only - Profile 1 may consolidate this duty into the ADM_ Red role set; Profile 2 and above separate them Service / Workload Accounts (e.g. ASV_ — Yellow) - Non-interactive automation identities - No MFA, no interactive sign-in - IP- and application-constrained - Regardless of how routine the underlying task feels, any account that can write to security posture, identity, or data exposure gets treated as privileged, not "just an app account" -------------------------------------------------------------------- This template is offered as a starting point, not a finished policy. Delete what doesn't apply, argue with the defaults, and make it yours. Full context and the story behind this framework: adam.cliffords.net/writing/stryker-lessons-learned/ --------------------------------------------------------------------