コードサイニング証明書の種別（EV/OV）とSmartScreen警告の関係、およびCI環境での自動署名について

Windowsアプリケーション（インストーラーおよび各種実行ファイル・DLL）の コード署名について、証明書の種別選定とSmartScreenの挙動に関して確認させていただきたく、問い合わせいたします。

現在、EVコードサイニング証明書＋USBトークンで署名運用をしておりますが、 署名処理をCI/CD（自動ビルド環境）に組み込むにあたり、USBトークンの 物理的な制約がボトルネックとなっているため、証明書種別の見直しを 検討しています。

以下の点について、ご教示いただけますでしょうか。

■ SmartScreenの挙動について

1. 現在のMicrosoft SmartScreenにおいて、EVコードサイニング証明書で署名した場合、署名直後から警告が抑制される（初期レピュテーションが付与される）という優遇措置は、現在も存在しますか？それとも、この挙動は廃止され、現在はEV・OVいずれもダウンロード実績（レピュテーション）の蓄積によって警告が解消される仕組みに一本化されていますか？
2. OV（組織認証）コードサイニング証明書で署名したアプリケーションが、SmartScreen警告を受けなくなるまでに必要な条件（ダウンロード実績の目安、期間など）について、一般的な基準はありますか？
3. 既に長年配布実績のあるアプリケーションについて、証明書をEVからOVへ変更した場合、これまで蓄積されたレピュテーションは維持されますか？それとも、証明書変更に伴いレピュテーションはリセットされ再度実績の蓄積が必要になりますか？

■ EV証明書が必須となる条件について

4. 2026年現在、EVコードサイニング証明書が「必須」となるのは、Windowsカーネルモードドライバーへの署名（Windows Hardware Developer Center Dashboardへの登録）のケースに限られる、という理解で正しいでしょうか？   

カーネルモードドライバーを含まない通常のアプリケーション・サービス・COMコンポーネント（例：Credential Provider）であれば、OV証明書での署名で問題ない、という認識で相違ありませんか？

■ CI環境での自動署名について

5. OVコードサイニング証明書の秘密鍵を、クラウドHSMやAzure Trusted Signing等のクラウドサービスに格納し、CI/CD環境（GitHub Actions等）から自動的にコード署名を行う運用はMicrosoftとして問題ない（SmartScreen等の評価上も不利にならない）ものでしょうか？
6. Azure Trusted Signingについて、現在日本国内の法人が利用可能な状況でしょうか？利用可能な場合、SmartScreenのレピュテーションは通常のOV/EV証明書による署名と同等に扱われますか？