A successful login answers only one part of an access decision. The user may enter the correct password, complete MFA and still connect from an unmanaged laptop, an outdated endpoint or a device that no longer meets the organisation’s security requirements.
Businesses therefore need to decide more than whether a user can authenticate. They also need to determine which devices can access sensitive systems, under what conditions and with what level of privilege.
Conditional access and device trust provide a way to make those decisions dynamically. Instead of granting the same access every time an identity authenticates, businesses can consider the user, device, requested resource and surrounding risk before allowing the connection.
Microsoft describes Conditional Access as an if-then policy model that combines signals with access controls. A policy might allow an employee to access routine applications after MFA but require a compliant managed device before granting access to financial or administrative systems. Microsoft’s Conditional Access policy model supports controls such as authentication strength, compliant devices and hybrid-joined devices.
This approach extends the principles behind Zero Trust endpoint security by turning identity and device information into practical access decisions rather than treating authentication as the final security checkpoint.
What Are Conditional Access and Device Trust?
Conditional access controls whether a user receives access based on defined conditions rather than relying on one fixed authentication rule.
A basic access model might say: If the password and MFA are correct, allow the user in.
A conditional model can ask much more:
- Who is signing in?
- Which application or resource are they requesting?
- What authentication method did they use?
- Is the endpoint managed?
- Does the device meet security requirements?
- Does the account hold privileged access?
- Does anything about the request create additional risk?
The organisation can then enforce a response that matches the situation.
For example, an employee using a managed and compliant laptop might access a sensitive cloud application normally. The same employee connecting from an unknown personal computer could face restricted access, stronger authentication or a complete block depending on the sensitivity of the resource.
Device trust provides the endpoint side of that decision.
Trust does not need to mean that the organisation considers a device permanently safe. Instead, it means that the business has enough reliable information about the endpoint to decide whether it meets the requirements for a particular activity.
Microsoft Intune, for example, can evaluate managed devices against compliance rules, while Microsoft Entra Conditional Access can use that compliance result when deciding whether to grant access. Microsoft’s device compliance guidance explains that compliance policies evaluate managed endpoints against defined configuration requirements and can feed the result into Conditional Access.
The important principle extends beyond Microsoft environments. Businesses should match the confidence they have in a user and device to the sensitivity of the resource they want to reach.
How Conditional Access and Device Trust Make Better Access Decisions
Conditional access works best when several reliable signals contribute to the decision. No single indicator should carry more trust than it deserves.
1. Verify the Identity Before Evaluating the Device
Access still begins with the user.
Strong authentication makes it harder for attackers to operate with stolen credentials, while account lifecycle management helps ensure that the identity itself remains legitimate. An inactive contractor account or former employee should not receive access simply because the correct credentials still work.
Authentication strength can also vary according to risk.
Routine workforce access may use one approved authentication method, while administrative accounts can require phishing-resistant authentication. This makes the authentication requirement proportionate to what the user can actually do after login.
The earlier move towards passwordless authentication can strengthen this layer because passkeys and FIDO2 security keys reduce exposure to phishing and reusable credential theft.
However, identity verification still does not establish whether the endpoint itself deserves access.
2. Determine Whether the Device Is Known and Managed
The next question concerns the device.
A business should know whether the endpoint belongs to the organisation, sits under an approved management platform and has an identifiable owner or purpose.
An employee might present valid credentials from both a corporate laptop and a personal home computer. Those devices should not automatically receive the same level of trust simply because the user remains the same.
Managed-device status provides stronger assurance because the organisation can apply policies, collect configuration information and respond when the endpoint falls outside expected standards.
However, management alone does not prove security. A managed laptop can still miss patches, lose contact with security tooling or drift away from its baseline.
That leads to the next decision.
3. Check Whether the Endpoint Meets Security Requirements
Device compliance turns endpoint condition into a usable access signal.
Depending on the platform and business requirements, a compliance policy might consider operating-system support, encryption, password or PIN configuration, security tooling and other device settings.
Microsoft documents this model directly through device compliance and Conditional Access, where organisations can require devices to meet defined compliance requirements before accessing protected resources. Microsoft also recommends testing new Conditional Access policies in report-only mode before enforcement to reduce the risk of accidental lockout.
Businesses should avoid treating “compliant” as a permanent security label. Compliance reflects whether a device currently satisfies the conditions the organisation has chosen to measure.
Those conditions need to be meaningful.
A policy that checks only whether the operating system has a PIN provides far less assurance than one that also considers current security posture, device management and endpoint protection.
An endpoint security assessment can help determine whether the security requirements behind device trust actually reduce realistic endpoint risk.
4. Match the Access Decision to the Resource
Not every application requires the same level of device assurance.
A company might allow employees to access low-risk collaboration services from personal devices while restricting payroll, customer records and administrative consoles to managed endpoints.
This risk-based approach improves security without forcing the strongest possible restrictions onto every activity.
Consider three employees using the same valid corporate identity system:
|
Access Request |
Device Condition |
Possible Access Decision |
| Read routine collaboration content | Personal device with MFA | Allow limited access |
| Access sensitive customer records | Managed, compliant laptop | Allow according to role |
| Open financial administration portal | Unmanaged endpoint | Require approved device or block |
| Perform cloud administration | Managed privileged workstation | Require stronger authentication and approved endpoint |
| Access business system from non-compliant corporate laptop | Known but unhealthy device | Restrict until compliance returns |
The exact policies will differ by organisation, but the principle remains consistent: higher-impact access should require stronger evidence of both identity and device trust.
5. Change the Decision When Risk Changes
Access should not remain trusted indefinitely simply because the user and device passed checks earlier.
A corporate laptop might fall out of compliance because it misses critical updates or stops reporting correctly. Security tools may detect suspicious behaviour after the user has already authenticated.
The business needs a way to respond when that context changes.
Microsoft’s compliance model allows device status to influence Conditional Access, while organisations can define actions when managed endpoints fail required policies.
From a broader security perspective, this allows the access model to react to changing risk instead of relying on yesterday’s trust decision.
A device may remain legitimate and company-owned while temporarily becoming unsuitable for high-risk access.
Practical Conditional Access and Device Trust Policies for Businesses
Conditional access delivers the most value when policies reflect real business risks rather than trying to create as many rules as possible.
1. Require Stronger Controls for Administrators
Administrative identities deserve more restrictive access conditions because compromise can create much greater impact.
Businesses can require privileged users to authenticate strongly and perform sensitive work only from approved managed endpoints.
Microsoft specifically publishes a policy pattern for requiring compliant or hybrid-joined devices for administrators, reflecting the additional risk associated with privileged accounts.
That policy principle can apply beyond one technology stack.
An administrator should not automatically gain high-impact access from an unknown laptop merely because they know the correct credentials and complete MFA.
Privileged identity, strong authentication and trusted endpoint requirements should reinforce each other.
2. Restrict Sensitive Applications to Suitable Devices
Finance platforms, customer databases, administrative portals and other sensitive resources often justify stronger device requirements than ordinary collaboration services.
A business could allow an employee to use webmail from a personal device while preventing the same endpoint from accessing a payroll system.
This distinction reduces exposure without forcing a blanket “corporate devices only” rule onto every application.
The organisation should decide which systems create enough risk to justify managed-device enforcement and document why those restrictions exist.
Security becomes easier to maintain when policy follows business impact rather than arbitrary technical categories.
3. Treat Unmanaged Devices Differently Rather Than Automatically Trusting Them
Remote work, contractors and BYOD can make complete device ownership unrealistic.
That does not mean unmanaged devices should receive the same access as endpoints the organisation controls.
Conditional access can support a middle ground.
Businesses might allow browser-only access, prevent downloads, restrict sensitive applications or require a managed endpoint before granting higher-risk capabilities. The exact controls depend on available technology, but the security objective remains clear: reduce what an unknown device can expose.
An unmanaged device is not necessarily malicious. The problem is that the organisation has less evidence about its security condition.
Access policy should reflect that uncertainty.
4. Protect Device Registration Itself
Device trust loses value if attackers can easily register their own systems as trusted devices.
The process that enrols, joins or registers an endpoint therefore deserves protection.
Microsoft supports requiring MFA during device registration, adding stronger assurance before users can associate new devices with the identity environment.
Businesses should also monitor unexpected device registrations, especially for privileged users or identities that rarely add new endpoints.
The organisation must trust the process that creates the device identity before it can rely on that identity during later access decisions.
Common Conditional Access and Device Trust Mistakes
Conditional access can strengthen security significantly, but poorly designed policies can create either excessive trust or unnecessary disruption.
One common mistake involves requiring MFA but ignoring the endpoint. MFA confirms additional evidence about the user, yet the account may still connect from devices the organisation cannot assess or protect.
Another problem appears when businesses equate registered with trusted. Device registration establishes identity, but it does not prove the endpoint remains patched, securely configured or free from compromise.
Weak compliance rules create a similar issue. A dashboard may label a device compliant because it satisfies minimal requirements, even though those requirements do not address the risks the organisation actually cares about.
Policy exclusions also deserve attention. Businesses often create exceptions for executives, legacy applications or troubleshooting situations. Temporary exclusions can become permanent and quietly bypass otherwise strong access policies.
Emergency accounts require a more deliberate approach. Microsoft recommends excluding carefully controlled break-glass accounts from certain Conditional Access policies so administrators can recover from accidental lockout, but those accounts need separate protection and monitoring rather than becoming ordinary exceptions.
Overly aggressive enforcement creates the opposite problem. A poorly tested policy can block legitimate users, interrupt business-critical applications or prevent administrators from accessing the environment.
For this reason, businesses should validate policies before broad enforcement, review sign-in results and keep recovery procedures ready.
Conditional access needs governance just as much as technical configuration.
How to Implement Conditional Access Without Creating Unnecessary Complexity
Start with the systems where inappropriate access would create the greatest business impact.
Administrative portals, finance applications, sensitive data platforms and cloud-management interfaces usually make better starting points than trying to apply complex device rules across every service immediately.
Next, establish dependable identity controls. MFA coverage, phishing-resistant authentication for high-risk users and clear account ownership provide a stronger base for later device-aware decisions.
Device visibility should follow. Determine which endpoints access business systems, which ones the organisation manages and what security requirements a device must meet before the business considers it suitable for sensitive access.
A broader identity and endpoint security posture assessment can help expose unmanaged endpoints, authentication gaps, excessive privileges and inconsistent controls before businesses begin enforcing stricter access policies.
From there, define a small number of understandable rules. For example, require strong authentication for all users, require compliant managed endpoints for sensitive systems and enforce tighter requirements for administrators.
Testing should come before enforcement. Microsoft recommends using report-only mode when evaluating new Conditional Access policies so teams can understand their likely effect before turning them on.
Organisations should also plan for device failure and user recovery. Employees will replace laptops, lose phones and occasionally fall out of compliance. A secure process must help legitimate users recover without creating an easy bypass for attackers.
Finally, review the policies as the environment changes. New applications, remote-working patterns, contractors and technology migrations can all change which access decisions make sense.
Aegixis Identity & Endpoint Security Services can support businesses that need to align access controls with endpoint hardening, least privilege, privileged access and wider device-security requirements instead of implementing conditional access as an isolated identity policy.
Final Thoughts
Conditional access turns authentication into a more useful security decision. Instead of asking only whether the user entered the correct credentials, businesses can consider whether the endpoint is managed, whether it still meets security requirements and whether the requested access justifies additional controls.
The aim is not to distrust every user or block every unmanaged device. It is to make access proportionate to risk. When identity, device trust and resource sensitivity influence the same decision, organisations gain a much stronger answer to the question that matters most: should this user, on this device, receive this access right now?
