Intune で証明書ベース認証をどう設計すべきか迷っているなら、2026年4月9日の Microsoft Cloud PKI ガイダンス更新は見逃せません。今回の更新で重要なのは、派手な新機能追加よりも、配置モデル、監視、CA 有効期限、削除と失効といった運用で止めないための考え方が明確になったことです。つまり、Intune 用 Microsoft Cloud PKI は「証明書を配る機能」ではなく、「証明書駆動型アクセスを安定運用する基盤」として位置づけるべきだ、というメッセージがより強くなりました。(Microsoft Learn)
Microsoft Cloud PKI は、Intune 管理デバイス向けの証明書発行・更新・失効をクラウドで簡素化するサービスです。オンプレミスのサーバー、コネクタ、専用ハードウェアを必須にせず、SCEP を使った証明書配布を Intune 側に寄せられるのが強みです。一方で、Wi‑Fi や VPN の利用先サーバーが使う TLS/SSL 証明書まで全部置き換えるわけではありません。この境界を正しく理解すると、今回のガイダンス更新の意味が見えやすくなります。(Microsoft Learn)
2026年4月9日の更新で押さえるべきこと
製品概要ページ自体は 2026年1月30日更新ですが、4月9日に更新されたのは Cloud PKI の運用周辺ドキュメントです。要するに Microsoft は、導入方法だけでなく、本番運用で詰まりやすい論点を補強した形です。(Microsoft Learn)
- 配置モデルの整理
更新された配置モデルのガイドでは、Cloud PKI root CAとBYOCAの2方式が明確に整理されました。さらに、証明書の信頼チェーンは Intune 管理デバイス側だけでなく、Wi‑Fi アクセスポイントや VPN サーバーなどの利用先にも必要であること、Android では AIA による親証明書探索に頼れず完全なチェーン配布が必要であることも明文化されています。(Microsoft Learn) - CA 有効期限対応の明文化
CA 有効期限が近づいたときは、現時点では管理者側で新しい issuing CA を作成し、該当する SCEP プロファイルの SCEP URI を差し替える必要があります。しかも、SCEP URI の更新だけでは証明書再発行は起きず、1つの SCEP プロファイルに複数 SCEP URI を持たせることもできません。(Microsoft Learn) - 監視の見方が整理された
Microsoft は、発行済み証明書の確認、issuing CA ごとのダッシュボード、SCEP 証明書レポートの見方を整理しました。証明書レポートの詳細反映には最大 24 時間かかることも明示されているので、配布直後に「失敗した」と誤判定しにくくなります。(Microsoft Learn) - 削除と失効の正式手順が具体化
CA を廃止する場合は、いきなり削除ではなく、Pause→Revoke→Deleteの順で進めます。しかも issuing CA を revoke する前に、その CA が発行した active なリーフ証明書を失効しておく必要があります。どの段階で何が元に戻せないかも、今回かなり明確になりました。(Microsoft Learn)
Microsoft Cloud PKI が戦略的な Intune 機能であり続ける理由
ここからは、公式ドキュメントを踏まえた実務目線の整理です。なぜ Microsoft Cloud PKI が今も戦略的な Intune 機能なのかは、単に「クラウドで証明書を配れるから」ではありません。
証明書ライフサイクルを Intune 側へ寄せられる
Microsoft Cloud PKI は、Intune 管理デバイス向けの専用 PKI をクラウドで提供し、証明書の発行・更新・失効を扱えます。しかも issuing CA 作成後は比較的短時間で証明書発行を開始でき、従来のように NDES サーバーや Intune Certificate Connector、そこに到達させるためのプロキシを前提にしなくて済む設計です。これは、証明書運用のボトルネックを“オンプレの中継構成”から外せる、という意味でかなり大きいポイントです。(Microsoft Learn)
証明書ベース認証の中核に置きやすい
Cloud PKI は Wi‑Fi、VPN、メール、Web、端末 ID といった証明書利用シナリオを前提にしています。公式の fundamentals でも、クライアント証明書による認証ハンドシェイクと、Cloud PKI が端末側のクライアント認証証明書を担う役割が整理されています。つまり、認証の入口を共有パスワードや手作業配布の証明書から外し、Intune で管理されたデバイスの信頼を使ってアクセス制御しやすくなるわけです。(Microsoft Learn)
ただし「PKI を全部置き換える」と考えるのは危険
誤解しやすい点ですが、Microsoft Cloud PKI は利用先サーバー側の TLS/SSL 証明書を提供しません。Wi‑Fi や VPN 接続時に、端末は先に利用先との TLS/SSL セッションを確立しますが、そのサーバー証明書自体は別の PKI や CA サービスで用意する必要があります。つまり Cloud PKI は、端末証明書の運用をクラウド化する機能であって、企業内の証明書基盤全体を一気に消し去る魔法のサービスではありません。ここを見誤ると、要件定義の段階で破綻します。(Microsoft Learn)
ADCS を残しながら段階移行できる
Cloud PKI が戦略的なのは、クラウドネイティブな新規構成だけでなく、既存 ADCS を持つ組織でも使いどころがあるからです。BYOCA では、オンプレミスまたは既存のプライベート CA に anchored した issuing CA をクラウド側で作成できます。さらに Microsoft は、Cloud PKI root CA と BYOCA issuing CA を同じ Intune テナント内で共存できると案内しています。これにより、「新規構成はクラウド、既存信頼チェーンは温存」という段階移行がしやすくなります。(Microsoft Learn)
監視・監査・権限分離まで Intune に寄せられる
Cloud PKI は発行だけではなく、監視と監査の設計も Intune 側に寄せやすいのが強みです。issuing CA ごとのダッシュボードでは active、expired、revoked、total issued を確認でき、グローバルな証明書一覧や SCEP レポートも見られます。加えて、監査ログは Intune 管理センターと Microsoft Graph API の両方から取得でき、CA の作成、取得、削除、リーフ証明書失効などを追跡できます。さらに、カスタムロールやスコープタグも使えるため、証明書運用を“属人的な管理者作業”から外しやすいのも実務上の利点です。(Microsoft Learn)
導入判断の基準
迷ったら、「どの信頼の起点を残すか」で判断すると整理しやすくなります。
Cloud PKI root CA が向くケース
次の条件が多いなら、Cloud PKI root CA を第一候補にしやすいです。(Microsoft Learn)
- 新規導入、またはクラウドネイティブ寄りに設計したい
- Wi‑Fi や VPN の利用先に、新しい信頼チェーンを配布しても問題ない
- NDES や Intune Certificate Connector への依存を減らしたい
- デバイス証明書の運用を Intune に集約したい
BYOCA が向くケース
一方で、次のような環境なら BYOCA の方が現実的です。(Microsoft Learn)
- 既存の ADCS やプライベート CA の信頼チェーンが、すでにネットワーク機器やサーバーへ広く配布されている
- 利用先の信頼アンカーをすぐには入れ替えられない
- 証明書発行だけを徐々にクラウドへ寄せ、ルート信頼は既存資産を活かしたい
- 一気に全面移行するより、共存期間を取ってリスクを下げたい
すぐ導入せず、先に設計を詰めるべきケース
次のパターンでは、先に要件整理をした方が安全です。(Microsoft Learn)
- Intune MDM 登録されていない端末にも同じ方式で証明書を配りたい
- 端末証明書だけでなく、利用先サーバーの TLS/SSL 証明書運用まで Cloud PKI で置き換えたいと考えている
- CA を用途別・部門別・地域別に細かく分けたいが、テナントあたりの CA 数制限に引っかかりそう
- 非 AD ドメインの利用先が多く、信頼チェーン配布を手動で回す運用が重そう
設計と導入で失敗しやすいポイント
EKU と CA 設計は後から足しにくい
Cloud PKI では、CA 作成後に主要プロパティを編集できません。後から EKU を追加したい場合は、新しい CA を作り直す必要があります。しかも Any Purpose EKU は過度に広く、Cloud PKI では使わない前提です。最初に「Wi‑Fi 用」「VPN 用」「ユーザー証明書用」など、どの用途を1本の CA にまとめるのかを決めておかないと、あとで再設計のコストが出ます。(Microsoft Learn)
SCEP プロファイルは URL と属性マッピングでつまずきやすい
SCEP Server URL では {{CloudPKIFQDN}} をそのまま残す必要があります。また、NDES の URL と Cloud PKI の SCEP URL を同じプロファイルに混在させてはいけません。さらに、SCEP プロファイルで使う属性が Microsoft Entra ID のユーザーまたはデバイス オブジェクトに存在しないと、証明書は発行されません。特にメールアドレスや UPN を件名に使う構成では、ディレクトリ属性の欠落がそのまま配布失敗になります。(Microsoft Learn)
信頼チェーン配布は端末側だけで終わらない
Cloud PKI の設計で最も多い失敗は、Intune 管理デバイスへの trusted certificate profile 配布だけで安心してしまうことです。実際には、Wi‑Fi、VPN、Web サービスなどの利用先にも、必要なルート CA や issuing CA の信頼チェーンが必要です。AD ドメイン参加サーバーなら GPO を使えますが、そうでなければ手動導入もあり得ます。特に Android では完全な証明書チェーンを返す必要があり、AIA 探索任せにはできません。(Microsoft Learn)
評価用 CA をそのまま本番に持ち込まない
見落としやすいのが、試用版で作成した CA と本番ライセンスで作成した CA の違いです。公式ドキュメントでは、ライセンス済みの Cloud PKI では HSM 署名・暗号化キーが自動利用される一方、試用期間中に作成した CA はソフトウェア ベースのキーを使い、購入後も HSM バックドに変換されないと案内されています。本番で鍵保護レベルを重視するなら、「試用で作った CA をそのまま使うか」を最初に判断しておくべきです。(Microsoft Learn)
証明書一覧の見え方を誤解しない
管理センターの issuing CA 画面で「すべての証明書を表示」を開くと、概要ページの既知の制限では最初の 1,000 件しか表示されないとされています。発行済み証明書を全体で確認したい場合は、Devices > Monitor > Certificates 側を使うのが実務的です。監視画面の違いを知らないと、「証明書が消えた」「失効したはずのものが見えない」といった誤解につながります。(Microsoft Learn)
CA期限切れ・失効・廃止の実務メモ
CA 有効期限が近づいたら
2026年4月9日に更新されたガイドで、Microsoft は現時点の有効期限対応をかなり明確にしました。やることはシンプルですが、見落としやすいです。(Microsoft Learn)
- 期限切れになる issuing CA と同じ Root CA Sourceで、新しい issuing CA を作成する。
- EKU やキーサイズなど、既存 CA の主要プロパティを揃える。
- 新しい CA の SCEP URI を取得し、古い URI を参照する SCEP プロファイルを差し替える。
- すべての SCEP プロファイルが新 CA を参照しているか確認する。(Microsoft Learn)
重要なのは、SCEP URI を差し替えても証明書再発行は自動で走らないことです。つまり、切り替え後の証明書更新タイミングは別途見ておく必要があります。また、1つの SCEP プロファイルに複数 SCEP URI は入れられません。なお Microsoft は、4月9日時点で「既存 CA の直接更新を今後サポート予定」と案内しています。(Microsoft Learn)
リーフ証明書を失効したら
リーフ証明書を手動で失効すると、その端末やユーザーに active な SCEP プロファイル割り当てが残っている限り、次回チェックインで新しい証明書要求が行われ、再発行されると Microsoft は案内しています。アクセスを止めたいのに再発行される、という事故はここで起きます。失効を“遮断”として使うなら、SCEP ポリシー割り当ての解除もセットで考えるべきです。(Microsoft Learn)
CA を廃止するとき
CA 廃止は、運用手順を間違えると影響が大きい作業です。Microsoft の正式手順は次の流れです。(Microsoft Learn)
- issuing CA を
Pauseする - その CA の active なリーフ証明書をすべて失効する
- issuing CA を
Revokeする - 最後に
Deleteする(Microsoft Learn)
Pause は再開できますが、Revoke と Delete は元に戻せません。しかも revoke 後は、CA は CRL/AIA への応答を続ける一方で、信頼チェーン上は信頼されなくなり、その CA が発行した既存のリーフ証明書は認証に使えなくなります。なお root CA は、ぶら下がっている issuing CA を削除しない限り削除できません。(Microsoft Learn)
まずやるべきこと
Cloud PKI を本気で使うなら、最初の一歩は大きな全面移行ではなく、小さくても運用まで通す検証です。
- まずは Wi‑Fi か VPN のどちらか1シナリオに絞る
- 利用先が既存ルートを前提にしているかを見て、
Cloud PKI root CAかBYOCAかを決める - EKU、件名設計、CA 数、ライセンス形態、試用版 CA を本番に残すかを先に決める
- trusted certificate profile と SCEP profile を 1 プラットフォームで作り、信頼チェーン配布まで確認する
- そのうえで、監視、失効、CA 期限切れ、CA 廃止の手順を運用手順書に落とす(Microsoft Learn)
今回のガイダンス更新が示しているのは、Microsoft Cloud PKI はもう「導入できるかどうか」を語る段階ではなく、「どうすれば止めずに回せるか」を詰める段階に入っているということです。Intune で証明書駆動型アクセスを広げたいなら、まずは 1 つのユースケースで、配布・監視・失効・有効期限対応まで一連の流れを検証するところから始めるのが、いちばん失敗しにくい進め方です。(Microsoft Learn)
コメント