Inventory and classify before promising dates
Every application should be classified by the authentication it can actually support: modern federation, header-based authentication behind a proxy, form-based login only, or no interceptable authentication at all. The classification drives both the integration pattern and the realistic timeline.
Attach a business criticality and a data sensitivity rating to each entry. A low-criticality application that cannot federate may be a candidate for retirement rather than engineering effort, and that is a legitimate outcome worth surfacing early.
Proxy and header-based patterns
For applications that trust an HTTP header, a reverse proxy that terminates the federated session and injects a verified identity header is the standard approach. It is effective but carries a real risk: any path that reaches the application without traversing the proxy allows header spoofing. Network controls must guarantee the proxy is the only route in.
Kerberos-constrained delegation covers Windows-integrated applications, letting a modern federated session translate into a Kerberos ticket for a downstream service. It requires careful service principal management, but it preserves the user experience without touching application code.
Password vaulting as a controlled fallback
Where no interception is possible, the pragmatic answer is credential vaulting: the identity platform stores the application credential and replays it after the user authenticates with a strong factor. This is weaker than federation — the credential still exists — but it delivers centralised access control, lifecycle revocation and audit logging where the alternative is a shared password in a spreadsheet.
Treat vaulting as a documented, time-boxed transitional state with an owner and a review date, not as a permanent architecture.
Adding MFA without breaking operations
Legacy systems rarely accommodate step-up prompts natively, so the factor challenge usually happens at the federation or proxy layer. That works well for interactive users and fails badly for batch integrations and service accounts, which must be identified and moved to certificate or key-based authentication before enforcement.
Roll out in waves with a clearly communicated bypass process and a monitored exception register. A programme that locks out a payments operations team on a Monday morning will lose the political support it needs to finish the tail.
Key takeaways
- Classify applications by achievable authentication pattern before committing to dates.
- Proxies and header injection work only when the proxy is the sole network path.
- Vaulting is an acceptable time-boxed fallback with an owner and a review date.
- Separate service accounts from interactive users before enforcing MFA.
Hiring or being hired in IAM?
TagWin Recruiting places Okta, Ping, SailPoint and CyberArk specialists with enterprises that cannot afford an identity gap.
Start an intake