That's a great analogy with the dashboard. So the "unified" view is really just showing the first leg of a two-leg journey. If the user provisioning breaks on the second leg, the console gives you a green checkmark for the first one, which sends you looking in the wrong place.
I'm learning about this split setup. Does that mean you end up building your own internal runbook to always check the PingFed bridge first for a certain class of errors, because the PingOne console can't be trusted for them?
PipelinePadawan
Yes, that's exactly what happens. You end up creating an internal checklist that starts with "Ignore the PingOne console success status for a minute, go check the PingFed audit logs." It adds a mandatory, manual step to every triage process.
But the hidden cost is the operational drift. When a new team member joins, you'll train them on the unified console first. The first few times they get burned by its false positive, they'll learn the internal runbook. But that institutional knowledge is brittle. It's a silent tax on onboarding and a risk during outages.
CloudCostHawk
Pain is about operational cost, not modernity.
You already have the team and the connectors for your on-prem Java muck. You'd have to rebuild all that custom work anyway for a PingOne bridge. That's months of sunk salary, not a feature.
The MFA question is the trap. PingOne gives you a second, paid policy engine just for cloud apps. You'll still need your PingFed rules for on-prem. So you'll configure and test MFA in two places, forever. That's double the compliance audit surface and tickets that start with "which system failed this time?"
Stick with the upgrade. Adding a third system (on top of Azure AD) just moves the pain to a more expensive console.
show the math
Your security lead is chasing modernity for its own sake, which is a great way to burn budget and make your life harder. You've already got the key pieces in front of you: Azure AD for the cloud apps, and a team that knows your PingFederate setup.
The "bridge" question is a trap. PingOne for a hybrid setup means you buy PingOne *and* still run a PingFederate bridge server for the on-prem legacy muck. You're just paying for two separate policy engines and consoles instead of one. Your specific worry about custom connectors? That work doesn't go away with PingOne, it just gets moved to a different, less-familiar configuration pane on that bridge node. You're trading known pain for a new, more expensive pain.
For MFA, PingOne centralizes policy only for the cloud side. Your on-prem Java apps and file servers will still require a separate MFA setup in PingFederate. Now you're maintaining, testing, and auditing MFA rules in two systems forever. Every rollout and troubleshooting ticket starts with figuring out which policy engine failed.
The upgrade path is less painful because it consolidates the complexity into a single system your team already understands. Extend your upgraded PingFederate to Azure AD. Let your project management and CRM tools hook into Azure AD directly, and use PingFed as the bridge for legacy. It's one stack, one set of logs, one place for MFA rules that apply to everything. Adding PingOne just gives you a shiny dashboard that lies to you about where the real problems are.
—davidr