Skip to main content

🚦🟠🚩CA - PRMFA for Device Join in Non-Trusted Countries

Adding a device to the tenant is a trust decision, not a form. Do it from a country you have no business being in, and a text-message code will not cut it.

🚦Type Conditional Access🟠Action Grant, phishing-resistant MFA🚩Target Device join from untrusted geo
reference-build Β· ca-prmfa-register-or-join-deviceGolden Master reference
License tier
Business Premium (Entra ID P1)
Control plane
Entra Conditional Access
Scope
All users, device-join action, non-trusted countries
Reversibility
report-only first, clean-revert

What this policy is about πŸš©β€‹

Registering or joining a device is one of the highest-trust moves in the tenant: the new machine becomes a thing Entra recognises, and from then on it can carry tokens, satisfy device-based controls, and generally be treated as one of the family. This policy says that when the join request arrives from a non-trusted country, ordinary MFA is not good enough. The grant requires an authentication strength of phishing-resistant MFA: a passkey, FIDO2 key, or certificate, the kind of factor an adversary-in-the-middle proxy cannot relay.

One does not simply walk a device into the tenant from Mordor. Not without a key that cannot be phished, anyway.

πŸ€” Why it bites

A device joined by an attacker is not a one-off breach, it is a permanent-ish foothold that then tries to pass your device-based policies from the inside. Blocking phishable factors at the join step, from the geographies you least trust, is where you stop that before it starts.

Why this matters πŸ•΅οΈβ€‹

Country by itself is a weak signal: VPNs, roaming staff and cloud egress all muddy it, which is why you do not hard-block here. But device join is not a routine sign-in, it is a state change that outlives the session, so it is exactly the action worth pinning to a stronger proof when the location is one you flagged as non-trusted. An attacker who has phished a password and a push approval can sail through normal MFA and enrol their own machine; a phishing-resistant factor is bound to the origin and simply does not relay, so the join dies at the door.

Scoping it to the Non-Trusted Countries named location keeps the friction where the risk is. Users joining devices from home stay on their normal path; only a device-join from a place you have marked as hostile has to produce a key instead of a code.

πŸ› οΈ Configuration​

Where: Entra admin center β†’ Protection β†’ Conditional Access β†’ Policies.

CA policy diagram: all users, Register or join devices action, from Non-Trusted Countries, grant requiring phishing-resistant MFA

SettingValue
Users, includeAll users
Users, excludeπŸ›‘οΈπŸ§‘β€πŸ’Όβ›“οΈπŸ”“πŸš¦Group - Break the Glass solution
Conditions, locationsInclude: πŸš©πŸ”΄NLOC - Non-Trusted Countries
Target resourcesUser action: Register or join devices
GrantRequire authentication strength: Phishing-resistant MFA
SessionNone

Note the target is a user action, not a cloud app: this fires on the register-or-join event itself, wherever it happens, rather than on access to any particular resource. Risk, device platforms, client apps and the device filter are all left unconfigured, so the only condition narrowing this is the location. That is deliberate, the whole point is "this specific action, from these specific places".

Roll it out in Report-only first and confirm the users who legitimately join devices already have a phishing-resistant factor registered, otherwise enforcement day is the day their enrolment quietly fails from abroad.

Caveats βš οΈβ€‹

Phishing-resistant means enrolled first. The grant is only as real as the passkeys behind it. If your users have never registered a FIDO2 key or passkey, this policy blocks their legitimate joins too. Drive authentication-method registration before you enforce, or the strength requirement is a wall with no door.

The named location is the whole scope. This only ever fires inside Non-Trusted Countries. Keep that list current, because a country you forget to add is a device-join this policy never sees.

It is not a substitute for a geo-block. This tightens the join action, it does not stop sign-ins from those countries. Pair it with the all-cloud-apps geo-block for the sign-in side; this covers the one action that block does not single out.

License and reversibility. Conditional Access and authentication-strength grants are Entra ID P1, included in Business Premium, no P2 needed here since there is no risk condition. Clean-revert: set it to Off and device joins from non-trusted countries drop back to ordinary MFA, which is exactly why a disabled copy of this belongs in drift detection.


A device join is a trust decision that outlives the session, so from the countries you trust least, make it prove itself with a key nobody can phish. 🚩