But if you're going to worry that a custom ROM might be compromised, shouldn't you also be worried that you know that the stock ROM contains unfixed critical security vulnerabilities? Wouldn't any reasonable argument to forbid the former also forbid the latter?

I'd say when something like a bank is involved, they need something more substantial to point at for their insurance arrangements if/when something goes wrong. "Our app allowed a $5000 transfer on the user's stock Samsung" is easier to grasp the state of the system they're playing in than a user modified one.

Also knowing what security risks are in play with N year old OS lets them decide if they want to allow the user to proceed or work around. Some applications are more aggressive in what version OS they need and that's a driver for upgrading phones, pushing the OEM to keep a phone in support for longer, or third party ROMs if this catch22 wasn't part of it.

> I'd say when something like a bank is involved, they need something more substantial to point at for their insurance arrangements if/when something goes wrong. "Our app allowed a $5000 transfer on the user's stock Samsung" is easier to grasp the state of the system they're playing in than a user modified one. Also knowing what security risks are in play with N year old OS lets them decide if they want to allow the user to proceed or work around. Some applications are more aggressive in what version OS they need

I've seen plenty of apps need a minimum major version of Android, but never any that have needed a minimum security patch level.

There are cases every day where an employee of a company can demonstrate that A is at least as good as B, but trying to get permission to do B is impossible.

There's simply no universe where an employee at a typical F500 company is going to be able to convince the IT team that they should permit custom code on phones even if the logic of the argument is sound. Even if they found the person, persuaded them, got them to persuade their management, in house legal teams, compliance teams etc., I seriously doubt whether the MDM solutions (eg InTune) would even have a checkbox to override the policy on one phone. To say nothing of the ongoing cost of tracking that one employee's specific setting.

This also plays a bit into the argument of why integrating your personal device into the corpo ecosystem of your employer is not a decision to be taken lightly.

> There's simply no universe where an employee at a typical F500 company is going to be able to convince the IT team that they should permit custom code on phones even if the logic of the argument is sound.

That's my point: I know that's how it is today, but the reasons for it being that way are illogical.