A company has staff only in the United States and Canada. After a series of credential-stuffing attempts against its cloud management console from other countries, the security lead wants console sign-ins from any other country blocked. Which control fits best, and what limitation should be planned for?
Select an answer to reveal the explanation.
Short Explanation
Geofencing is like a guard who only lets in cars with local plates, which works until someone borrows a local car. You block by country at sign-in, and you keep MFA because a VPN can fake the plates. The trap is reaching for subnet rules that never see console sign-ins at all.
Full Explanation
Geofencing restricts access based on the geographic location associated with a request, usually derived from the source IP address. Applied in the identity provider's sign-in or conditional access policy, it blocks console authentication attempts from countries where the company has no staff, cutting a large share of opportunistic credential-stuffing traffic. Its limitation is that location is inferred, so an attacker using a VPN, proxy or compromised host inside an allowed country passes the check; geofencing must therefore be layered with strong multifactor authentication and monitoring. Network security group rules on workload subnets filter traffic to the company's virtual machines, but the management console is a provider-hosted service reached through the identity layer, so those rules never see the sign-ins. Data residency settings determine where data is stored and processed; they have no effect on who may authenticate from where. TLS protects session confidentiality and integrity in transit, yet it does not stop an attacker from establishing a perfectly valid encrypted session with stolen credentials. Exam caveat: geofencing also appears in data residency discussions, but here it is an access control. Operational check: review blocked sign-in events after enabling the policy and confirm break-glass accounts are excluded and monitored.