Yes. The facade in a strangler fig migration intercepts every request headed to the legacy system and the new services, so it is the highest value component in the design. Give it authentication, authorization checks, rate limits, logging, patching and a tested rollback, like any production edge component.
Why the facade matters
Microsoft's description of the pattern puts a facade, a proxy, between clients and both systems. It routes each request to the legacy application or to a new service, and it shifts more traffic to the new side as migration proceeds. The same guidance warns that the facade must not become a single point of failure or a performance bottleneck.
From a security view, that single point is also a single place to enforce policy. Used well, it is an advantage. Used carelessly, it becomes a trusted hop that hides who the real caller was.
Controls to put on the facade
- Authenticate at the edge. Do not rely on the legacy app's session handling alone. If the new services expect tokens and the old app expects cookies, the facade translates, and that translation code needs review.
- Pass identity downstream. Forward the verified user identity, not just the facade's own service account. Otherwise every backend sees one caller and audit trails lose meaning.
- Apply the same rate limits and request size limits to both routes. Legacy endpoints are often the weakest on input validation.
- Log routing decisions. Record which backend served each request, so you can answer "was this handled by old or new code?" during an incident.
- Keep route rules in version control and review them. A mistyped rule can expose an internal path or skip a check.
- Patch the proxy software on a schedule. It sits on the edge and runs third party code.
Mistakes that show up in practice
| Mistake | Why it hurts |
|---|---|
| Legacy app still reachable directly | Attackers bypass the facade and its controls |
| Facade trusts forwarded headers from clients | A caller can claim to be any user |
| Different timeouts for old and new routes | Slow legacy calls pile up and cause outages |
| Route rules edited by hand in production | No review, no rollback record |
The first one is the most common. Once the facade exists, firewall or network rules should allow the legacy application to accept traffic only from the facade. Check this with a test from outside, not by reading the config.
Testing the facade during migration
Each time a route flips from legacy to new, run the same set of authorization tests against both paths. Behavior should match, including error responses. A new service that returns more detail in errors than the old one can leak internals, and one that returns less can break clients in ways that push teams to add exceptions.
Keep a short list of routes still pointing at legacy code. That list is also your remaining exposure map, and it shrinks as the migration moves forward. Pair it with the dependency findings for each legacy module so that the facade team and the app teams share one view.
A note on decommissioning
Azure's guidance ends with removing the facade once the client talks directly to the new system. Before that happens, make sure the controls the facade enforced have moved into the new services or a standard gateway. Otherwise removing it quietly drops a layer of protection.
Safeguard policies and gates can help here by blocking changes to the facade's repository when they introduce known vulnerable dependencies, and its scanning covers both the legacy and new repositories in one inventory. A free scan is at gold.safeguard.sh/scan.
Quick check
Should the legacy app still accept direct traffic?
No. Restrict it to traffic from the facade, and verify that from outside the network.
Who owns the facade?
Name one team. Shared ownership usually means nobody patches it.
Sources
Last reviewed: 19 October 2026.
