Qué vas a conseguir
Un conjunto de políticas de acceso condicional que entiende la sede: dentro de la oficina, con un equipo gestionado, el trader trabaja sin fricción; fuera, o con un equipo que no es de la empresa, se le pide más o no entra. Las aplicaciones de trading y las consolas de administración tienen sus propias reglas, más duras. Y nada de eso se activa sin haberlo visto antes en modo solo informe, porque una política mal hecha a las 8:00 deja a una sala entera sin acceso a la apertura.
Antes de empezar
- Las IP públicas de salida de la sede, de todos los circuitos (principal y respaldo) y del proveedor de proxy o SASE si el tráfico sale por él. Te las da el equipo de redes, no una prueba en un navegador.
- Licencias Microsoft Entra ID P1 como mínimo (P2 si vas a usar condiciones de riesgo).
- Los equipos gestionados con Intune y su política de cumplimiento funcionando.
- Las dos cuentas de emergencia creadas y documentadas antes de tocar nada.
- La lista de aplicaciones que el negocio considera críticas: plataforma de órdenes, portales de mercado con SSO, consolas de administración.
1. La sede como ubicación con nombre
- Todos los circuitos: si solo das de alta el principal, el día que el tráfico salga por el respaldo la sede dejará de ser "de confianza". Es el ticket de la sección 5.
- Un nombre que diga qué es y de dónde sale. Si hay varias sedes, una ubicación por sede y un grupo de ubicaciones solo si de verdad las tratas igual.
- La ubicación no sustituye al dispositivo conforme: una IP de la oficina con un portátil personal conectado a la WiFi de invitados (si sale por la misma IP) no debería tener el mismo trato. Por eso la red de invitados sale por otra IP.
2. El diseño por capas
| Política | Usuarios | Aplicaciones | Condición | Control |
|---|---|---|---|---|
| CA01 Base | Todos | Todas | Cualquier ubicación | MFA, salvo desde la sede con dispositivo conforme |
| CA02 Dispositivo | Todos | Microsoft 365 | Cualquiera | Dispositivo conforme o unido híbrido |
| CA03 Trading | Grupo de mesas | Apps de trading con SSO | Fuera de la sede | Bloquear |
| CA04 Trading en sede | Grupo de mesas | Apps de trading con SSO | Sede | Conforme y MFA, frecuencia de inicio de sesión diaria |
| CA05 Administración | Roles de administración | Todas | Cualquiera | Fuerza de autenticación resistente a phishing |
| CA06 Heredada | Todos | Todas | Clientes de autenticación heredada | Bloquear |
- Las apps de trading suelen tener una regla de negocio detrás: no se opera desde casa o solo desde equipos de la mesa. La política la refleja, no la inventa: pide la regla por escrito.
- Las consolas de administración y los roles privilegiados piden FIDO2 o Windows Hello for Business, desde cualquier sitio, también desde la sede.
- Evita una política por cada excepción. Si un caso no encaja, primero pregunta si el caso es correcto.
3. Cuentas de emergencia y otras exclusiones
- Las dos cuentas de emergencia se excluyen de todas las políticas mediante un grupo, solo de nube, con credenciales resistentes a phishing guardadas en sitios distintos. Cada inicio de sesión de esas cuentas genera una alerta que llega al equipo.
- Las cuentas de recurso de las salas (Teams Rooms) y las cuentas de servicio no deben quedar sin control: van excluidas de las políticas de usuarios y cubiertas por una suya (solo desde la sede, solo las aplicaciones que usan).
- Cada exclusión tiene dueño y motivo en la descripción de la política. La revisión mensual las repasa.
4. Primero en modo solo informe
Toda política nueva o cambiada se crea en Solo informe al menos una semana, con un día de mercado completo dentro. Mientras tanto:
- En los registros de inicio de sesión, la pestaña de acceso condicional muestra qué habría hecho cada política en modo solo informe. Busca los "Solo informe: error" y entiende cada uno antes de activar.
- Activa en martes o miércoles fuera de horario de mercado, nunca un lunes a primera hora ni el día antes de un cierre.
5. El ticket: "en la sede de repente piden MFA todo el rato"
Martes, 9:20. Varias mesas dicen que Outlook y Teams les piden MFA una y otra vez, y que la plataforma de órdenes no les deja entrar. Ayer todo iba bien.
- El patrón: es a todos los de la sede y desde la misma hora. Eso apunta a la ubicación, no a los usuarios ni a los equipos.
- Desde qué IP llegan los inicios de sesión:
Connect-MgGraph -Scopes AuditLog.Read.All, Policy.Read.AllGet-MgAuditLogSignIn -Filter "createdDateTime ge 2026-10-27T07:00:00Z" -Top 500 | Group-Object IpAddress | Sort-Object Count -Descending | Select-Object -First 2 Count, NameCount Name----- ---- 412 198.51.100.44 61 203.0.113.18$loc = Get-MgIdentityConditionalAccessNamedLocation | Where-Object DisplayName -eq 'SEDE-MADRID-SALIDA'$loc.AdditionalProperties.ipRanges.cidrAddress203.0.113.16/29- La causa: el tráfico de la sede sale desde esta mañana por
198.51.100.44, el circuito de respaldo, y ese rango no está en la ubicación con nombre. Para Entra ID, la sede está "fuera". - Confírmalo con redes: una caída del circuito principal, un cambio del proveedor o un ajuste del SD-WAN en el firewall. Si el cambio es legítimo, añade el rango del respaldo a la ubicación (con su cambio registrado) y los avisos paran en minutos.
- Que no se repita: el procedimiento de cambios de red incluye "actualizar ubicaciones con nombre" y la alerta de caída del circuito principal avisa también al equipo de identidades.
No resuelvas el ticket desactivando la política o añadiendo "todas las IP" como confianza. Es la forma más rápida de abrir la puerta a cualquier sitio.
6. Lo que revisas cada mes
- Las IP de la ubicación contra lo que el equipo de redes dice que existe hoy.
- Las exclusiones de cada política: quién está y por qué.
- Los inicios de sesión de las cuentas de emergencia (debería haber cero, salvo la prueba trimestral).
- Las políticas que siguen en solo informe más de un mes: o se activan o se borran.
- Los errores de acceso condicional del mes por política, para detectar una regla que bloquea más de lo previsto.
Siguientes pasos
- La guía de Entra ID: Conditional Access del Nivel 3 explica cada condición y control y cómo se construye una política paso a paso.
- La guía de Intune cubre la política de cumplimiento en la que se apoya CA02.
- La de Microsoft 365: Global Admin y PIM cubre los roles privilegiados de CA05.
- La de Fortinet FortiGate explica por qué circuito sale el tráfico de la sede.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A set of Conditional Access policies that understands the site: inside the office, on a managed device, the trader works without friction; outside, or on a device that isn't the company's, more is asked or access is denied. Trading apps and admin consoles have their own, tougher rules. And none of it goes live without being seen first in report-only mode, because a badly built policy at 8:00 leaves a whole floor without access at the open.
Before you start
- The site's public egress IPs, from every circuit (primary and backup) and from the proxy or SASE provider if traffic leaves through it. The network team gives you them, not a test in a browser.
- At least Microsoft Entra ID P1 licences (P2 if you will use risk conditions).
- Devices managed by Intune with a working compliance policy.
- The two break-glass accounts created and documented before you touch anything.
- The list of apps the business considers critical: order platform, market portals with SSO, admin consoles.
1. The site as a named location
- Every circuit: if you only add the primary, the day traffic leaves through the backup the site will stop being "trusted". That's the ticket in section 5.
- A name that says what it is and where it egresses. With several sites, one location per site, and a group of locations only if you genuinely treat them the same.
- The location doesn't replace the compliant device: an office IP with a personal laptop on the guest WiFi (if it leaves through the same IP) shouldn't get the same treatment. That's why the guest network egresses through another IP.
2. The layered design
| Policy | Users | Apps | Condition | Control |
|---|---|---|---|---|
| CA01 Baseline | All | All | Any location | MFA, except from the site on a compliant device |
| CA02 Device | All | Microsoft 365 | Any | Compliant or hybrid joined device |
| CA03 Trading | Desk group | Trading apps with SSO | Outside the site | Block |
| CA04 Trading on site | Desk group | Trading apps with SSO | Site | Compliant and MFA, daily sign-in frequency |
| CA05 Admin | Admin roles | All | Any | Phishing-resistant authentication strength |
| CA06 Legacy | All | All | Legacy authentication clients | Block |
- Trading apps usually have a business rule behind them: no trading from home, or only from desk machines. The policy reflects it, it doesn't invent it: ask for the rule in writing.
- Admin consoles and privileged roles require FIDO2 or Windows Hello for Business, from anywhere, including the site.
- Avoid one policy per exception. If a case doesn't fit, first ask whether the case is right.
3. Break-glass accounts and other exclusions
- The two break-glass accounts are excluded from every policy through a group, cloud-only, with phishing-resistant credentials stored in different places. Every sign-in by those accounts raises an alert that reaches the team.
- Room resource accounts (Teams Rooms) and service accounts must not be left uncontrolled: they are excluded from the user policies and covered by one of their own (only from the site, only the apps they use).
- Every exclusion has an owner and a reason in the policy description. The monthly review goes through them.
4. Report-only first
Every new or changed policy is created in Report-only for at least a week, with a full market day inside it. Meanwhile:
- In the sign-in logs, the Conditional Access tab shows what each report-only policy would have done. Look for "Report-only: Failure" results and understand each one before enabling.
- Enable on a Tuesday or Wednesday outside market hours, never first thing on a Monday or the day before a close.
5. The ticket: "users at the site are suddenly asked for MFA all the time"
Tuesday, 9:20. Several desks say Outlook and Teams keep asking them for MFA, and the order platform won't let them in. Yesterday everything was fine.
- The pattern: it's everyone at the site, from the same time. That points at the location, not the users or devices.
- Which IP the sign-ins come from:
Connect-MgGraph -Scopes AuditLog.Read.All, Policy.Read.AllGet-MgAuditLogSignIn -Filter "createdDateTime ge 2026-10-27T07:00:00Z" -Top 500 | Group-Object IpAddress | Sort-Object Count -Descending | Select-Object -First 2 Count, NameCount Name----- ---- 412 198.51.100.44 61 203.0.113.18$loc = Get-MgIdentityConditionalAccessNamedLocation | Where-Object DisplayName -eq 'SITE-MADRID-EGRESS'$loc.AdditionalProperties.ipRanges.cidrAddress203.0.113.16/29- The cause: since this morning the site's traffic leaves through
198.51.100.44, the backup circuit, and that range isn't in the named location. To Entra ID, the site is "outside". - Confirm with networks: a primary circuit outage, a provider change or an SD-WAN adjustment on the firewall. If the change is legitimate, add the backup range to the location (with its change logged) and the prompts stop within minutes.
- So it doesn't repeat: the network change procedure includes "update named locations", and the primary circuit down alert also notifies the identity team.
Don't close the ticket by disabling the policy or trusting "all IPs". It's the quickest way to open the door to anywhere.
6. What you review each month
- The location's IPs against what the network team says exists today.
- Each policy's exclusions: who is there and why.
- Break-glass account sign-ins (there should be none, except the quarterly test).
- Policies still in report-only after a month: either enable or delete them.
- The month's Conditional Access failures by policy, to spot a rule blocking more than intended.
Next steps
- The Level 3 Entra ID: Conditional Access guide explains each condition and control and how to build a policy step by step.
- The Intune guide covers the compliance policy CA02 relies on.
- The Microsoft 365: Global Admin and PIM guide covers the privileged roles in CA05.
- The Fortinet FortiGate guide explains which circuit the site's traffic leaves through.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →