Asesoramiento sobre certificados para implementar software con código firmado como un proveedor externo

Estoy en el proceso de desarrollar una aplicación para una organización, y estoy buscando un control de cordura en mi estrategia, especialmente dada la naturaleza de la estupidez de SuperFish que se expuso.

Los usuarios están en un dominio de Windows y la aplicación de escritorio se implementará como una aplicación ClickOnce. Estos paquetes de implementación se pueden firmar para que cuando el usuario los instala, los vea como un editor de confianza en lugar de como un "Editor desconocido".

1. Tendremos un certificado raíz autofirmado para desarrollo interno (CERT # 1)
2. Creamos un certificado de aplicación específico firmado por ese certificado raíz con el único fin de firmar el código (eku 1.3.6.1.5.5.7.3.3) (CERT # 2)
3. Usamos CERT # 2 para firmar la solicitud
4. La clave privada y la contraseña CERT # 1 se almacenan de forma segura en el sitio. Solo los administradores de dominio (NO LOS DESARROLLADORES) tienen acceso a la clave o al conocimiento de la clave de acceso.
5. La clave pública del certificado raíz se envía al dominio como un certificado de confianza.
6. Los desarrolladores TIENEN acceso al CERT # 2 porque necesitan realizar las compilaciones, realizar implementaciones.

No veo ninguna manera de dar a los desarrolladores acceso al segundo certificado. Pero en este contexto, significa proveedores de terceros. El personal en el sitio no tiene la experiencia para tomar el código de los desarrolladores y realizar implementaciones internamente. Pero si asume que este certificado se filtrará con el tiempo, debe asumir que las entidades externas tendrán la capacidad de firmar el código y representarlo como "confiable" para los miembros del dominio.

¿Existen otras ideas para hacer que esta implementación sea segura?

Me mata enseñar a las personas a instalar aplicaciones que se muestran como poco confiables, pero me pregunto si esa no es una mejor opción ya que se instalará desde dentro de la red local, y de hecho, de hecho, generalmente será instalado por el personal de TI antes de que el usuario recién contratado comience a trabajar.