💻 Device Posture

[kchudy]

Device Posture — Feature Specification

License

• This is an enterprise feature

Purpose

• Device Posture blocks insecure devices from connecting to VPN locations.
• A device is considered insecure if it fails at least one required posture check.
• The feature is strict by design: failure means access is denied.

Scope

• MVP applies only to VPN access.
• Posture is enforced at VPN connection time.
• No advisory mode in MVP.
• No bypass or exception mechanism in MVP.
• No dry-run mode in MVP.
• No dashboards in MVP.
• No posture versioning in MVP.
• Future scope may include advisory checks, dry-run, exceptions, dashboards, and extensibility.

Core Concepts

• Admins define posture checks.
• A posture check contains OS-specific requirements.
• A posture check may include one or multiple operating systems.
• Each operating system has its own independent set of rules.
• Only rules matching the user device OS are evaluated.
• If the device OS is not included in the posture, access is denied.
• If posture cannot be evaluated, access is denied.

Supported Operating Systems

• Windows
• macOS
• Linux
• iOS
• Android

Posture Rules

• Minimum operating system version.
• Operating system update recency, for example:
  • no update restriction
  • updated within 1 month
• Security conditions, depending on OS support:
  • connected to Active Directory
  • antivirus installed
  • disk encryption enabled
• Minimum Defguard client version.
• Option to allow or block pre-release Defguard client versions.

Posture Creation Flow

• Admin opens the Posture Checks section.
• Admin starts a new posture check.
• Admin selects operating systems.
• Admin configures rules per selected OS.
• Admin configures Defguard client version requirements.
• Admin adds posture name and description.
• Admin reviews a summary before saving.
• Admin confirms creation.

Location Assignment

• Postures are assigned to VPN Locations.
• One Location can have multiple postures assigned.
• One posture can be assigned to multiple Locations.
• When evaluating the postures of a location, sum the postures (rules from posture A AND rules from posture B)
• A posture can be assigned:
  • from the Location edit screen
  • from the posture details/list screen
• If a Location has no posture assigned, all devices are allowed from a posture perspective.

Enforcement

• When a user connects to a VPN Location, the device is evaluated against the postures assigned to that Location.
• Client collects raw posture signals from the device.
• Server evaluates the posture decision.
• Client-side result is not trusted as the source of truth.
• If all required checks pass, VPN access is allowed.
• If any required check fails, VPN access is denied.
• If the OS is not included in the posture, VPN access is denied.
• If signals are missing or posture cannot be evaluated, VPN access is denied.

User Failure Experience

• User receives a clear failure message when access is denied.
• Failure message explains which posture checks failed.
• Failure reasons should be specific enough to help the user fix the issue.
• Example failure reasons:
  • OS version is too old
  • device was not updated recently enough
  • disk encryption is disabled
  • antivirus is not installed
  • Defguard client version is too old
  • operating system is not allowed
  • posture could not be evaluated

Posture List View

• Admin can view all existing posture checks.
• List shows posture title.
• List summarizes requirements per OS.
• Admin can open posture details.
• Admin can access actions such as edit, duplicate, assign, or delete if supported.

Posture Details View

• Admin can inspect full posture configuration.
• Details are grouped by operating system.
• Admin can see Defguard client version requirements.
• Admin can see which Locations use the posture.
• Admin can assign posture to Locations from this view.

Activity Log

• Posture-related access decisions are recorded in the Activity Log.
• Logs include posture failures.
• Logs should include:
  • user
  • device
  • location
  • timestamp
  • event type
  • result
  • failure reason
• Admin can filter Activity Log entries to find posture-related events.

Security Model

• Server is the source of truth for evaluation.
• Client provides raw signals only.
• A modified client should not be able to bypass server-side posture enforcement.
• The MVP should not be marketed as strong hardware-backed device attestation.
• It is policy-based endpoint posture enforcement.

Deferred Features

• Advisory/non-blocking checks.
• Dry-run posture mode.
• Temporary bypasses or exceptions.
• Posture versioning and rollback.
• Compliance dashboard.
• Device posture status overview.
• Custom scripts or plugins.
• Custom admin-defined remediation messages.
• Posture enforcement for non-VPN features.

Decisions

• OS versions dictionaries will be stored in Core, if an admin wants to have latest versions while creating postures he needs to keep Core up to date
• Windows has a separate channel for feature updates and security updates. We will set security updates in the postures.
• For Linux we support Debian, Ubuntu, Arch, Fedora, Redhat. In linux posture check we will have kernel version check (not the OS version).
• For mac include posture "System integrity protection"
• Client will pull and check postures periodically
• For windows we will have a posture for system version, and security updates up to date.