Docs

Appearance

Runbook: Twingate Device Compliance Enforcement ​

Purpose ​

Twingate is the primary remote-access layer for Cirius Group. Today it allows any authenticated user with a valid corporate account to connect; the client device's security posture is not evaluated. Device compliance enforcement turns Twingate into a zero-trust gate — a resource request is granted only if the user is authenticated and the device meets compliance criteria (Intune enrollment, OS patch level, encryption, anti-malware, etc.).

This runbook walks through the configuration, the staged rollout (report-only then enforce), and the dependencies on FIDO2 hardware distribution.

Related story: FIDO2-016. Related:

  • runbooks/intune-usb-storage-block.md
  • runbooks/intune-mam-mobile.md
  • entra/fido2-auth-method.tf.example
  • security/arctic-wolf-mdr-scope-gap.md

How Twingate Device Compliance Works ​

Twingate's Device Security feature evaluates posture signals at connection time and per resource request. Sources of posture:

  • Twingate native signals: OS version, client version, disk encryption, anti-malware running, screen lock
  • Third-party posture via integration: Intune (primary for Cirius), CrowdStrike, Jamf, and others
  • Trust scoring: Posture signals are combined into a "Trust Level" (High / Medium / Low), and resource policies require a minimum Trust Level before access is granted

Cirius will use Intune as the primary posture source because Intune is already the device-management system of record for managed Windows devices and iOS/Android via MAM. Twingate reads Intune compliance via the Intune Graph API integration.

Prerequisites ​

Before turning enforcement on, all of the following must be true:

  1. Intune enrollment — every staff-used device that needs to reach corporate resources is enrolled (managed Windows) or under MAM (personal phones). See intune-usb-storage-block.md and intune-mam-mobile.md.
  2. Intune compliance policies exist defining what "compliant" means per platform — OS patch floor, encryption required, anti-malware running, passcode required, no jailbreak/root.
  3. FIDO2 hardware distributed to the three domain admins (Rory, Kevin, Greg) and any other privileged users — because the Conditional Access policies that lift sign-in assurance to FIDO2 are a partner to this rollout. See entra/fido2-auth-method.tf.example.
  4. Twingate–Entra SSO is live (it already is) — Twingate authenticates users against Entra before device posture is even evaluated.
  5. Twingate–Intune integration is configured in the Twingate admin portal: Settings → Device Security → Integrations → Microsoft Intune → connect the tenant app registration with DeviceManagementConfiguration. Read.All Graph permission.
  6. Break-glass paths documented so the 18 break-glass accounts retain a way to reach resources if the Twingate / Intune chain fails. Per CLAUDE.md, break-glass accounts are never suppressed and must continue to work via their designated path.

Posture Signals to Require ​

Windows (managed / Intune-enrolled) ​

  • Intune compliance state = Compliant
  • BitLocker encryption active on the system drive
  • Defender for Endpoint agent running and reporting
  • Cortex XDR agent running and reporting
  • OS build within the patch floor (Windows 10 ≥ 22H2 or Windows 11 ≥ 23H2, adjusted rolling)
  • Screen lock timeout ≤ 15 minutes (enforced via Intune)

macOS (future — none today) ​

Documented for future-proofing; no policy effect until macOS devices are in scope.

iOS / Android (MAM) ​

  • Intune app protection policy applied (MAM)
  • OS version within the floor (see intune-mam-mobile.md)
  • Not jailbroken / rooted
  • Device attestation available (DeviceCheck on iOS, Play Integrity on Android)

Unmanaged personal computer (edge case) ​

  • Default: block
  • Exception: read-only webmail / Teams web via a browser session behind a CA policy that already gates on compliant device or MFA + MDM + session controls. Twingate's role here is a hard deny — if users need that edge case, we direct them through the web path, not through Twingate.

Twingate Resource Policies ​

Organize resources into tiers and apply trust requirements per tier.

TierResourcesMinimum Trust Level
Tier 0 — privilegedJump hosts, domain controller management, Palo Alto Panorama, Veeam management, Intune / Entra admin portals (when accessed via Twingate)High + FIDO2 auth at sign-in
Tier 1 — sensitivePHI-adjacent workloads (Medicare workflow host, SQL DB replicas accessed for admin), Key Vault access, Terraform state storageHigh
Tier 2 — standardInternal file shares, Teams / SharePoint admin routes, general business applicationsMedium
Tier 3 — supportPrinter management, low-sensitivity internal toolingMedium (Low accepted during report-only)

"High" Trust Level requires all Windows posture signals above plus Intune Compliant state. "Medium" allows slightly relaxed patch floors (current minus one minor OS release) but still requires Compliant + Encryption + AV running.

Path in Twingate admin ​

For each resource: Resources → <resource> → Security → Minimum trust level → <tier>. Apply the mapping above.

Group-based assignment: use the existing PrivilegedUsers, AllStaff, and ContractorAccess Entra groups mapped into Twingate as user groups; resource policies combine group membership with trust level.

Rollout Plan — Report-Only First, Then Enforce ​

Phase 1 — Report-only (Weeks 0–4) ​

Purpose: collect data on who would be blocked and why, without blocking anyone. This is the learning phase.

  • [ ] Configure posture signal definitions in Twingate for all platforms
  • [ ] Configure resource Trust Level requirements per the tier table above
  • [ ] Set the global enforcement mode to "Report-only" for the evaluation period
  • [ ] Enable Twingate audit logging export to the central LAW (cirius-logging-law-central — see CLAUDE.md Log Analytics section)
  • [ ] Weekly review: which devices would be blocked, which users are affected, and why
  • [ ] Fix the systemic issues first (a missing Intune compliance policy, an out-of-date OS on a fleet of devices, an exception group that needs to exist for a specific workflow)

Phase 2 — Enforce on Tier 0 only (Weeks 4–6) ​

  • [ ] Flip enforcement on only for Tier 0 resources
  • [ ] Requires Rory / Kevin / Greg have FIDO2 distributed and enrolled by this point
  • [ ] Monitor closely — block on privileged resources is a sharper blade than Tier 2 and will surface any remaining blind spots quickly

Phase 3 — Enforce on Tier 1 (Weeks 6–8) ​

  • [ ] Flip enforcement for Tier 1 resources
  • [ ] Expect a short burst of help tickets; resolve by either bringing the device into compliance or approving a time-bound exception

Phase 4 — Enforce broadly (Week 8+) ​

  • [ ] Flip enforcement for Tier 2 and Tier 3
  • [ ] Full zero-trust posture in effect

Rollback ​

  • At any point during staged enforcement, a per-tier rollback is a single setting flip back to Report-only
  • Global rollback to Report-only is also a single setting — takes effect on next session for connected clients; new connections immediately reflect the change

Exception Handling ​

Exceptions are time-bound and device-specific, never user-wholesale.

  1. Request via SecOps story in COMP project titled Twingate compliance exception — <device> — <reason>
  2. Include: user, device ID, what posture signal is failing, why the device cannot meet it in the normal timeframe, expiry date (default 14 days)
  3. Reviewed by Rory (technical) and Adriana (compliance)
  4. If approved, Rory adds the device to a Twingate-side exception group permitted to connect at a lower trust level for the specified resources for the specified window
  5. At expiry, membership is removed; user re-requests if still needed

All exceptions appear in the Twingate audit log and remain visible in the SecOps story history.

Logging and Monitoring ​

  • Twingate connection logs and posture evaluations are exported to cirius-logging-law-central via the Twingate log exporter / event hook
  • An agent in the security monitoring fleet (see CLAUDE.md agents listing, agents/network/ or create under agents/twingate/) watches for:
    • Repeated compliance failures for the same user in a short window (possible compromised credentials)
    • New devices first appearing with Low trust — alert to review
    • Break-glass accounts connecting via Twingate — always CRITICAL alert, never suppressed (consistent with the break-glass rule in CLAUDE.md)
  • Monthly review in runbooks/monthly-security-review.md — section on remote access — confirms trust distribution across the fleet remains at ≥ 95% High for privileged users and ≥ 90% Medium or better for all staff

Dependencies on FIDO2 Hardware Distribution ​

Tier 0 enforcement is gated on FIDO2 keys being distributed and enrolled for Rory, Kevin, and Greg. Do not flip Tier 0 into enforce mode until:

  • YubiKey 5-series hardware is in hand for all three (purchasing + shipping needs to land before the Phase 2 target date)
  • FIDO2 auth method policy is enabled in Entra (see entra/fido2-auth-method.tf.example)
  • Each has completed a first sign-in with FIDO2 and confirmed the key works
  • Conditional Access policy requiring phish-resistant MFA for admin roles is enabled in enforce mode

If any of these dependencies slip, hold Phase 2 — do not compensate by relaxing the Tier 0 requirement.

Compliance Mapping ​

  • HIPAA 164.312(a)(1) — access control (device posture as access prerequisite)
  • HIPAA 164.308(a)(4)(ii)(B) — access authorization procedures
  • HIPAA 164.312(d) — person or entity authentication (authenticated user + trusted device together)
  • SOC2 CC6.1 — logical access controls
  • SOC2 CC6.6 — trusted access credentials and device posture
  • SOC2 CC7.2 — monitoring remote access for anomalies
  • HITRUST 01.j Access Control for Portable Media / Mobile Devices

Auditor evidence:

  • Twingate resource policy configuration (screenshots)
  • Intune compliance policies (screenshots / exports)
  • Sample Twingate audit log entries showing compliance evaluation
  • Exception log from SecOps for the audit period

Known Gotchas ​

  • Twingate Client update lag: Some clients report posture signals after a delay when the client has just upgraded. Keep the Twingate client update cadence in users' minds (monthly review flag) so stale clients do not cause false compliance failures.
  • Intune reporting lag: Intune compliance state can lag real device state by up to several hours on first enrollment. Post-enrollment, plan for ~1 hour lag during normal operation.
  • MacOS personal devices: Currently out of scope. Block by default via Twingate until macOS management is introduced — do not create a permissive gap hoping users will self-manage.
  • Split-tunneling: Twingate uses split-tunnel by default. This does not affect compliance enforcement (posture is evaluated at resource request time regardless of tunnel shape), but it does change the threat model for lateral movement; document this in the network architecture diagram.
  • Break-glass account paths: Break-glass accounts must have an alternate path when Twingate is down or the Intune integration is unhealthy; do not collapse their path onto Twingate-only access.

Internal use only — Cirius Group