Our IT department is blocking one particular browser for security reasons — what is the actual reason?

Speaking as someone who has written one of these announcements: the stated reason is usually a simplification, and the real reason is almost always manageability rather than vulnerabilities.

The common drivers:

• Policy control. Enterprise environments push settings centrally — allowed extensions, certificate handling, blocked sites, update enforcement. Browsers differ a lot in how well they integrate with a given management stack, and one that cannot be centrally configured is a browser IT cannot make guarantees about.
• Traffic inspection. Regulated industries are often required to inspect outbound traffic. Browsers that maintain their own certificate store, or resolve names over their own encrypted channel by default, bypass the inspection infrastructure. That is a feature for a user and a compliance failure for the organisation.
• Supportability. Every additional browser is another platform to test internal applications against and another set of support calls.
• Attack surface reduction. Fewer installed applications is genuinely a security position, independent of any one product's record.

Notice that none of those mean the browser is insecure. "We cannot manage it" is a real security concern and it is not the same statement.

If you want to raise it constructively rather than argue, the question that gets a real answer is: "is there a managed configuration of this browser that would meet the requirement?"

That asks about the underlying constraint rather than the decision, gives the team room to say what the actual blocker is, and occasionally results in a supported configuration being offered. Asking why the browser is considered insecure gets you the announcement read back at you.

The traffic inspection point deserves expanding because it is the one that generates most of these decisions in banks and similar sectors.

Organisations under regulatory obligations frequently have to be able to see what leaves the network — for data loss prevention, for retention, for monitoring. That is implemented by terminating and re-encrypting connections at a gateway, which requires the browser to trust an internal certificate authority.

A browser that ships its own trust store, and that will use its own encrypted name resolution unless told otherwise, breaks that arrangement by default. The gateway stops seeing anything and the organisation stops meeting its obligations.

It is usually configurable rather than impossible. But "configurable if every managed device is correctly configured" is a weaker guarantee than "not installed", and a security team that has been burned once will choose the stronger one.

There is also a plainer possibility that is worth holding open: it may not be about security at all.

Standardising on one browser reduces licensing complexity, support cost and internal application testing. "Security risk" is a phrase that ends discussion in a way that "we would rather support one thing" does not, so it gets used for decisions whose real justification is operational.

That is not necessarily dishonest — reducing variety genuinely does reduce risk — but it does mean the announcement should not be read as a technical assessment of the product.