What your device shares during pre-sign-in device checks

TL;DR — Before sign-in, a Zero Trust system may ask your device for a small set of security facts such as device ID, operating system version, encryption status, screen lock status, and whether required security software is present. The key takeaway: these checks usually share posture data (security state), not your personal files or browsing history, and the most important decision is whether you need a lightweight browser-based check or full device management. Reading time: ~7 min

What it is and where it sits

When a company "checks your device before sign-in," it is usually doing a device posture check (a test of your device's security state) as part of Zero Trust access control. In Zero Trust, access is not granted just because you know the password or are on the office network. The system also asks: Is this the right user, on an acceptable device, in an acceptable condition, for this app?

The device check sits between your attempt to sign in and the app you want to use. It is often handled by an identity provider or IdP (the service that manages sign-in), sometimes with help from a device management or security agent already installed on the device.

In a typical flow:

• You open an app or website.
• The app redirects you to the sign-in service.
• The sign-in service asks the device, browser, or installed agent for posture information.
• The sign-in service compares that information to policy.
• If the device passes, you continue signing in.
• If not, you are blocked or sent to a remediation page.

This replaces older "inside the network = trusted" thinking. Instead of trusting a VPN connection or office Wi‑Fi by default, the system evaluates the device each time access matters.

[User Device] ---- 1. open app ----> [App]
[App] ---- 2. redirect to sign-in ----> [IdP / Access Proxy]
[User Device] ---- 3. posture facts ----> [IdP / Access Proxy]
[IdP / Access Proxy] ---- 4. policy check ----> [Policy Engine]
[Policy Engine] ---- 5. allow/deny ----> [IdP / Access Proxy]
[IdP / Access Proxy] ---- 6. token or block ----> [App]
[App] ---- 7. access granted/denied ----> [User Device]

What information is typically shared

The exact list depends on how strict the organization is and what tooling it uses, but common examples are:

• Device identifier: a unique ID for the device, often from device management.
• User association: which employee or contractor the device is assigned to.
• Operating system details: Windows 11, macOS 14, iOS version, Android patch level.
• Compliance state: whether the device matches company rules.
• Disk encryption status: whether storage encryption is turned on.
• Screen lock / passcode status: whether a PIN, password, or biometric lock is required.
• Security software presence: whether endpoint protection or an approved browser is installed.
• Jailbreak / root status: whether phone protections have been bypassed.
• Certificate presence: whether a device certificate (a digital ID stored on the device) exists.
• Basic browser facts: browser version, sometimes whether cookies and secure storage are available.
• Network context: IP address, rough location, whether traffic comes through a corporate gateway.

Usually not needed for pre-sign-in posture checks:

• Your personal documents
• Your photos
• The contents of your email
• Your browser history
• Keystrokes
• Full file listings

That does not mean no tool can ever collect more. It means a normal pre-sign-in device check does not need those things to decide whether the device meets policy.

How it actually works

Let’s walk one realistic example: an employee uses a company-managed MacBook to open an internal HR app.

End-to-end example

1. The employee opens https://hr.example.com in a browser.
2. The HR app sees there is no valid session and redirects the browser to the company sign-in service.
3. The sign-in service asks for user authentication, such as password plus MFA (multi-factor authentication).
4. Before finishing sign-in, the sign-in service also checks device posture.
5. The browser or local device agent sends a small set of facts, for example:
   • device ID: mac-7f2c...
   • OS: macOS 14.7
   • encryption: enabled
   • screen lock: enabled
   • management status: managed
   • endpoint protection: running
   • certificate: present
6. The policy engine compares those facts to rules such as:
   • only managed devices may access HR
   • macOS must be 14.5 or newer
   • disk encryption must be on
   • endpoint protection must be active
7. If all checks pass, the sign-in service issues a token (a signed proof that you authenticated and met policy).
8. The browser sends that token back to the HR app.
9. The HR app grants access.

If one check fails, the result changes:

• If the MacBook is unmanaged, access may be denied completely.
• If the OS is slightly outdated, access may be allowed only to low-risk apps.
• If encryption is off, the user may be sent to a page explaining how to fix it.

Why the system asks before sign-in

Doing the check before sign-in completion helps avoid issuing a valid session to a device that should not have one. In Zero Trust terms, the device becomes part of the access decision, not an afterthought.

Browser check vs installed agent

There are two broad ways this data is collected:

• Browser-based check: The sign-in page learns limited facts from the browser and network context. This is easier to roll out, but it can only see so much.
• Agent or device-management check: A local agent or management profile reports richer posture data such as encryption, compliance, or certificate status. This is stronger, but more invasive and more work to operate.

When to use it (and when not to)

Use pre-sign-in device checks when the app or data is sensitive enough that "correct password + MFA" is not enough on its own.

You probably don't need this if...

• The app is public and has no sensitive data.
• You only need basic account security and MFA already solves most of the risk.
• Your team cannot support device enrollment, lost-device handling, and policy exceptions.
• Your users are mostly external customers using personal devices, and requiring management would create too much friction.

Trade-offs

Every benefit here costs something.

The privacy angle

The practical question is not "Does the system inspect the device at all?" It does. The real question is "What is the minimum information needed to make a safe access decision?"

A good Zero Trust design asks for the smallest useful set of facts. For many organizations, that means collecting compliance status and a few device attributes, not broad surveillance data.

In practice

Below are two examples you can adapt today: one policy example and one user-facing remediation example.

Example 1: Access policy logic

{
  "application": "hr-portal",
  "require": {
    "mfa": true,
    "device.managed": true,
    "device.encrypted": true,
    "device.screen_lock": true,
    "device.os_family": ["macOS", "Windows"],
    "device.os_min_version": {
      "macOS": "14.5",
      "Windows": "11.0.22631"
    }
  },
  "deny_if": {
    "device.rooted": true,
    "device.jailbroken": true,
    "device.endpoint_protection": "missing"
  }
}

This shows the kind of facts a policy engine evaluates before sign-in is completed. The gotcha: version comparisons are easy to get wrong, so test with real devices on both sides of the threshold before enforcing broadly.

Example 2: Reverse proxy passing device posture headers

location / {
    proxy_pass http://hr_app;
    proxy_set_header X-User-Email $http_x_authenticated_user_email;
    proxy_set_header X-Device-ID $http_x_device_id;
    proxy_set_header X-Device-Managed $http_x_device_managed;
    proxy_set_header X-Device-Compliance $http_x_device_compliance;
}

This pattern is common when an access proxy sits in front of an internal app and forwards trusted identity or device facts as HTTP headers. The gotcha: the app must trust headers only from the proxy, never directly from the internet, or an attacker could spoof them.

Example 3: User-facing remediation message

<h1>Device check required</h1>
<p>You signed in successfully, but this device does not meet access rules for the HR portal.</p>
<ul>
  <li>Disk encryption: Off</li>
  <li>Screen lock: On</li>
  <li>Device management: Present</li>
</ul>
<p>To continue, turn on disk encryption in your device settings, then try again.</p>

This is the kind of message users need when a posture check fails. The gotcha: avoid vague text like "device not compliant" by itself; tell the user exactly which check failed and what action to take.

Where you would configure this

Because vendor dashboards differ, look in your provider's admin console for sections with names like:

• Security → Conditional Access
• Access → Policies
• Identity → Device Trust
• Endpoint Management → Compliance Policies
• Certificates → Device Certificates

A common rollout order is:

1. Create the device compliance policy in your endpoint management tool.
2. Enroll a small pilot group of devices.
3. In your identity or access dashboard, create an access rule for one sensitive app.
4. Start in report-only or monitor-only mode if your provider offers it.
5. Review failures for a week.
6. Switch the policy to enforce.

⚠️ Turning on enforcement too early can block legitimate users from critical apps. Start with one app and a pilot group, and keep a break-glass admin account (an emergency account protected separately) that is excluded from the new rule.

Further reading

• NIST SP 800-207 Zero Trust Architecture
• OpenID Connect Core
• OAuth 2.0 Authorization Framework
• The "Authentication" and "HTTP headers" sections of the MDN Web Docs
• The device compliance and conditional access sections of your identity provider's official admin documentation

This article was written by an AI system and published pending human review. Verify anything you intend to act on.