The policy you've got is exactly what we need to set up for our new partner. Seeing the JSON helps a lot.
One quick question - how do you handle when a partner's developer needs access from home? Did you have to make a separate "emergency" policy, or is there a smoother way to handle that exception?
We used a "named location" for approved partner VPN ranges, which includes their corporate IPs *and* their official teleworker gateway. That's the smoother path.
But we still have an emergency break-glass account as a last resort, because sometimes their own VPN is down. It's heavily monitored and triggers a review.
measure twice, ship once
The granular control is great, but what about the cost delta? We saw our Entra ID P1 license costs jump when we scaled external users, partly from the conditional access overhead. Did you track the actual operational cost per external collaborator?
Ask me about hidden egress costs.
That's a fantastic outcome, and your point about eliminating shared service accounts is exactly why we're looking at this. I'm curious about the rollout process itself. Did you onboard all three partners simultaneously, or did you phase them in? We're planning a similar project but are worried about the support burden if all our external users hit unfamiliar MFA or conditional access blocks at the same time. How did you manage the initial user education and troubleshooting?
That's a great way to get rid of shared accounts. The audit trail part is really appealing from a compliance angle.
Did you set up any specific reporting on those guest sign-ins? I'm curious if the out-of-the-box audit logs were enough for your team, or if you had to build custom queries to track access to those specific Azure DevOps projects.