An Underwriters Guide to Cyber Risk: Managing 3rd Party Risk – Part 3

Due to the length of this detailed topic, it will be broken into multiple parts. Previous portions here:

An Underwriters’ Guide to Cyber Risk: Managing 3rd Party Risk – Part 1
An Underwriters’ Guide to Cyber Risk: Managing 3rd Party Risk – Part 2

Technical Approvals in Cybersecurity: A Missing Pillar of Risk Management

In traditional industries, technical approval processes are a vital part of ensuring safety and reliability. For example, companies often pay to have their devices tested and approved by organizations like UL, which rigorously test products to ensure safety and reliability. Safety-critical devices—such as fire alarms, fire pumps, and safety doors—require approval before being used by insured parties, giving insurers the confidence that these devices will perform when needed.

Cybersecurity, however, lacks a similar robust system of technical approvals. Without an established process, standards in cybersecurity are often vague and difficult to enforce. For instance, many standards simply state that an organization must have a “firewall” or use “industry-standard encryption.” These requirements are difficult to enforce because they are vague—what exactly qualifies as an acceptable firewall, and who verifies it? There are many products that could meet these requirements on paper, but without an approval process, there is no consistent or provable standard of quality.

Technical approvals are ultimately an absolutely necessary step to establishing universally high standards. This is what will, eventually, end the problem of high levels of third party risk forever. It is an unavoidable part of standardizing risk management in technology and reign in losses. It will, unfortunately, be difficult to make great progress in cyber security until such time as a robust system of independent testing and approval is established. This will create the “ecosystem of trust” that is necessary to enforce security.

A Well-Established and Necessary Process
It is unusual that cybersecurity proceeds without technical approval, but this reflects an outdated mindset in IT, where buyers assume all risk without warranties or guarantees. Technical approval is a well-established process in many industries, providing independent verification that a product meets specific standards and ensuring accountability. It is no longer the 1980’s, and software and IT products are no longer specialty products or experimental, but this mentality still persists.

Testing Security Products: The Torture Tests
Consider how physical security products are evaluated: safes are subjected to extreme conditions, locks are picked, and bulletproof vests are literally shot at. This rigorous testing ensures these products meet required safety standards.

The image to the right shows a safe being tested by Underwriters Laboratories. Typically, safes and vaults are tested to prove that they can stand to acetylene touches, plasma lances and even explosives. Although all consumer products are tested for safety, those with a security function typically receive special attention of this type. Most physical security products meet varying standards or grades of security, often based on how long they can be anticipated to resist attacks.

In cybersecurity, penetration testing (pen testing) serves a similar function by finding vulnerabilities before attackers do. In high-security environments, pen testing is essential for validating security. When conducted thoroughly by skilled testers, pen testing can provide strong assurances similar to those achieved by physical product testing.

Economics and Stakeholder Involvement
The process of technical approval is made economical through collaborative efforts involving insurers, manufacturers, and industry groups. The government typically does not have the resources for detailed evaluations alone. However, by distributing costs—usually requiring manufacturers to bear the burden—technical approval becomes a standard cost of doing business.

Manufacturers provide samples for testing as part of their quality control, ultimately protecting themselves from liability. Insurers enforce standards by collaborating with trade organizations like IEEE or NFPA, helping codify requirements and fund testing.

Once standards are set, insurers can enforce them by requiring non-compliant equipment to be retired or insured under high-risk policies. This collaboration reduces risks for all stakeholders and ensures that products meet established safety standards.

The Need for Technical Approval in Cybersecurity
A technical approval process includes thorough evaluations and lifecycle management, meaning approved technologies are updated if new weaknesses are found or phased out if they no longer meet modern standards. This gives standards real enforceability.

For example, instead of vague requirements like “an industry-standard firewall,” specifying “a firewall from an approved vendor, following specific setup guidelines” creates measurable standards that can be enforced. This is why we need technical approvals in cybersecurity: they ensure organizations prove compliance through standardized, independent evaluations, just as they would with fire safety devices.

The Problem with MFA Requirements: A Case Study
A familiar example of vague cybersecurity standards is Multi-Factor Authentication (MFA) requirements. Many insurers require companies to implement MFA, but without technical approval, these requirements are largely ineffective.

What is MFA? It involves using two or more factors to verify identity:

  1. Something you know: A password or PIN.
  2. Something you have: A hardware token or device, which could be insecure.
  3. Something you are: Biometrics like a fingerprint.
  4. Somewhere you are: Geolocation-based factors.

Not all MFA implementations are created equal. Is SMS-based MFA acceptable? Industry experts consider SMS insecure, yet it often qualifies as MFA. Similarly, geofencing or certain biometrics can be spoofed. Without technical approval, there is no standardized enforcement of which methods are secure and which are not.

Additionally, the MFA itself may not be enforced across all accounts or it may be of a type that allows users to opt out. There are also types of MFA, such as “Push MFA” which are not secure because they are easy for end users to accidentally click through. To complicate matters more, there are options provided for how a person can recover their access, should their device be lost or stolen and these may provide a much weaker back door.

If insurers and regulators evaluated solutions like Okta, Duo, or Microsoft Authenticator—approving configurations and ensuring best practices—we would see meaningful improvements. Defining acceptable MFA solutions, how they should be configured, and the conditions for lifecycle management would drive real security, rather than vague compliance.

Conclusion: Technical Approvals Are Long Overdue

Technical approvals are a vital part of risk management, especially where reliability and safety are crucial. Insurance companies have historically enforced these approvals, ensuring only thoroughly tested technologies are used to mitigate risks. This practice is well-established in fields like fire safety and electrical systems.

It is a glaring oversight that this approach has not been extended to cybersecurity. As digital infrastructure grows and the Internet of Things (IoT) blurs the lines between consumer safety and cybersecurity, technical approvals must become part of standard risk management. IoT devices, which combine cybersecurity and physical safety, make standardized approvals even more pressing.

This gap in technical approvals for cybersecurity is costing us. The lack of specific, enforceable standards leaves organizations vulnerable to inconsistent protections and higher risks. Insurance companies must enforce the use of rigorously tested technologies to raise the bar for cybersecurity. It’s time to stop accepting vague promises and demand certified solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *