【Okta】Okta Verify のデバイスポスチャセンサーモードで共用 Windows 端末を自動登録し管理対象にする

はじめに

こんにちは、ネクストモードのゆきなわです。

本記事では、Okta Verify のデバイスポスチャセンサーモード (Device Posture Sensor Mode)（以下、センサーモード）を使い、共用 Windows 端末を利用者の操作なしで Okta に登録し、認証ポリシーの「登録済み」と「管理対象」の条件を満たすまでの手順を解説します。

登録に使うデバイス証明書と、管理証明 (Management attestation) に使う管理証明書は、どちらも Okta を認証局 (CA) とする委任 SCEP で発行し、Microsoft Intune から配布します。

※ 本記事は2026年10月時点の情報に基づいています。センサーモードは早期アクセス (Early Access) の機能のため、画面や仕様は変更される場合があります。

背景

Okta の認証ポリシーでは、アクセス元の端末について、デバイスの状態 (Device state) が「登録済み (Registered)」であることや、デバイス管理 (Device management) が「管理対象 (Managed)」であることを条件にできます。端末の登録は、通常は利用者が Okta Verify でアカウントを設定したときに行われます^[1]。

一方で、複数の利用者が交代で使う共用端末では、利用者ごとに Okta Verify へ登録する運用が負担になります。センサーモードを使うと、MDM から配布した端末単位の証明書で端末を Okta に登録でき、利用者が個別に Okta Verify に登録する必要はありません^[2]。

これまで、Okta Verify が収集する OS のバージョンやディスク暗号化などのデバイスのシグナルは、利用者が Okta Verify に登録するまで Okta に届かず、認証ポリシーで利用できませんでした^[3]。センサーモードで登録した端末は、利用者が認証する前からシグナルを Okta に送ります。そのため、Okta Verify に登録していない利用者のサインインでも、認証ポリシーで「登録済み」の条件とデバイス保証ポリシーを適用できます^[4]。

登録済みと管理対象

センサーモードで満たせるのは、認証ポリシーの「登録済み」の条件です。「管理対象」を条件にする場合は、管理証明書が別に必要です^[2]。センサーモードの登録に使うデバイス証明書も MDM から配布しますが、デバイス証明書だけでは管理対象とは判定されません。管理証明では、認証のたびに Okta が管理者の構成した発行者のリストを端末に送り、Okta Verify はその発行者が発行したクライアント証明書を読み込みます^[5]。単一の証明書発行者を使用しない org では、デバイス証明書は管理証明とは別の CA が発行するため、管理証明には使用されません。

「登録済み」は、利用者が Okta Verify でアカウントを設定した端末でも満たされます^[1]。会社が管理する共用端末に限定する場合は、「管理対象」もあわせて条件にします。

本記事では、2つの証明書の配布から、「登録済み」「管理対象」とデバイス保証ポリシーを条件にする認証ポリシーまでを扱います。

管理証明書を利用者ごとに Intune で配布する手順は、個人端末を想定した過去の記事で紹介しています。

検証の全体像

本記事で構成する環境の全体像は次のとおりです。共用端末に配布する2つの証明書と Okta Verify が、アプリサインインポリシーのルールにある3つの条件にそれぞれ対応します。利用者は、それぞれ別の Microsoft Entra ID のアカウントで Windows にサインインします。Okta Verify には登録しないまま、この3つの条件を満たした端末からアプリにサインインできます。

登録までの流れ

センサーモードでは、次の1から4の流れで、利用者の操作なしに端末が Okta に登録されます。5は、登録した端末から利用者がサインインしたときの流れです。

1. Intune が、Okta の CA 証明書と、2つの証明書の SCEP 証明書プロファイルを端末に配布します。
2. 端末が鍵ペアを作成し、Okta の SCEP URL に証明書を要求します。Okta は、Microsoft Entra ID に登録したアプリの資格情報で Intune にチャレンジを確認し、証明書を発行します。
3. Intune が、センサーモードのオプションを付けて Okta Verify をインストールします。
4. 端末の Okta Verify が、デバイス証明書を使って端末を Okta に登録します。Okta は、端末と証明書を結び付けます。
5. 利用者がアプリにサインインすると、Okta が認証ポリシーで「登録済み」とデバイス保証ポリシーの条件を判定します。

管理証明書は、端末の登録には使用されません。利用者がサインインすると、Okta Verify が管理証明書で管理証明を行い、認証ポリシーの「管理対象」の条件が評価されます。検証では、管理証明書は端末からの最初のサインインのときに端末に結び付けられました（pki.cert.bind）。

前提

本記事の対象は、Microsoft Entra 参加済みで Intune に登録され、利用者がそれぞれの Microsoft Entra ID のアカウントでサインインする共用 Windows 端末です。前提とする構成と検証環境は次のとおりです。

センサーモードには、Okta Verify for Windows 7.2 以降が必要です^[2]。2026年10月25日時点のリリースノートでは、7.2.1 の展開先は Preview の org（2026年10月21日）だけで、Production の org への展開日は記載されていません^[7][8]。

Production の org でも、早期アクセスの版は取得できます。Okta Admin Console の「設定」>「ダウンロード」には「一般利用可能のダウンロード」と「早期アクセスのダウンロード」があり、2026年10月25日時点の検証環境（Production の org）では、それぞれの版は 7.1 と 7.2 でした。検証では、「早期アクセスのダウンロード」から取得した 7.2 を使用しました。

単一の証明書発行者 (Single certificate issuer) を有効にした org では、「デバイス統合」の画面が「証明書の構成」「認証局」「管理証明」「デバイス登録」の4つのタブに変わり、手順2の操作が異なります^[9]。本記事では、この機能を使用しない画面で説明します。

設定の流れ

手順1から手順5が設定作業です。設定の後、「動作の確認」のセクションで、証明書の配置、端末の登録、サインインを確認します。

手順1：Microsoft Entra ID のアプリ登録

委任 SCEP では、Intune が証明書の要求ごとにチャレンジを生成し、Okta がそのチャレンジを確認してから証明書を発行します^[10]。Okta が Intune に問い合わせてチャレンジを確認するための資格情報として、Microsoft Entra ID にアプリを登録します。

1. Microsoft Entra 管理センターの「アプリの登録」で「新規登録」を選択し、シングルテナントのアプリを作成します。リダイレクト URI は空欄のままにします。
2. アプリの「概要」で、アプリケーション (クライアント) ID を控えます。あわせて、テナントのプライマリドメイン（例：xxx.onmicrosoft.com）を控えます。
3. 「証明書とシークレット」でクライアントシークレットを作成し、値を控えます。
4. 「API のアクセス許可」で次のアプリケーションの許可を追加し、管理者の同意を与えます。
   • Intune：scep_challenge_provider
   • Microsoft Graph：Application.Read.All

Microsoft Graph の User.Read は、アプリの登録時に既定で追加される委任されたアクセス許可です。検証では削除せずに使用しました。

Okta のドキュメントは、デバイス証明書と管理証明書の手順でそれぞれアプリを登録する構成ですが、必要な権限は同じです。本記事では、1つのアプリを手順2の2つの SCEP 構成で使用し、クライアントシークレットの有効期限を1か所で管理します。検証でも、1つのアプリで2つの証明書が発行されました。

クライアントシークレットの有効期間は、最長24か月です^[11]。期限が切れると2つの証明書の発行と再発行が止まるため、「運用上の注意」のセクションの手順で期限前に更新します。

手順2：Okta での機能の有効化と SCEP URL の生成

Okta Admin Console で、早期アクセスの機能を有効にしてから、デバイス証明書用と管理証明書用の SCEP URL をそれぞれ生成し、用途ごとの Okta の CA 証明書をダウンロードします。2つの SCEP URL は、手順3の SCEP 証明書プロファイルで使用します^[12][13]。

早期アクセスの機能の有効化

Okta Admin Console の「設定」>「機能」で、早期アクセスの機能「Okta Verifyデバイスポスチャセンサーモード」を有効にします。この機能を有効にしないと、「認証局」タブに Device Access 向けの Okta CA が表示されないため、SCEP URL の生成より先に有効にします。

デバイス証明書の SCEP URL

1. 「セキュリティ」>「デバイス統合」の「デバイスアクセス」タブで、「SCEP構成を追加」を選択します。
2. 「SCEP URLチャレンジタイプ」で「動的SCEP URL」を選び、「Microsoft Intune（委任SCEP）」を選択します。
3. 「AADクライアントID」「AADテナント」「AADシークレット」に、手順1で控えた値を入力します。AAD テナントにはプライマリドメインを入力します。
4. 「生成」を選択し、表示された SCEP URL を控えてから「保存」を選択します。

管理証明書の SCEP URL

1. 「セキュリティ」>「デバイス統合」の「エンドポイント管理」タブで「プラットフォームを追加」を選択し、「デスクトップ（WindowsおよびmacOSのみ）」を選んで「次へ」を選択します。
2. 認証局に「Oktaを認証局として使用」を、「SCEP URLチャレンジタイプ」に「動的SCEP URL」の「Microsoft Intune（委任SCEP）」を選択します。
3. 「AADクライアントID」「AADテナント」「AADシークレット」に、手順1で控えた値を入力します。AAD テナントにはプライマリドメインを入力します。
4. 「生成」を選択し、表示された SCEP URL を控えてから「保存」を選択します。

「エンドポイント管理」タブの SCEP 構成の画面は、過去の記事で紹介しています。

Okta の CA 証明書のダウンロード

「セキュリティ」>「デバイス統合」の「認証局」タブで、「Okta CA (Device Access向け)」と「Okta CA (エンドポイント管理向け)」のそれぞれについて、「アクション」列にある x509 証明書のダウンロードアイコンを選択します。ダウンロードしたファイルは、拡張子を .cer に変更します。

単一の証明書発行者を使用しない org では、「認証局」タブに用途ごとの CA が表示されます^[9]。デバイス証明書は Device Access 向けの CA が、管理証明書はエンドポイント管理向けの CA が発行します。2つの CA の証明書は名前（サブジェクト）が同じため、取り違えないよう、ダウンロードしたファイルは用途が分かる名前で保存します。

手順3：Intune の構成プロファイルの作成

Intune では、信頼された証明書プロファイルと SCEP 証明書プロファイルを、証明書ごとに1つずつ作成します。1つの SCEP 証明書プロファイルに2つの SCEP URL を入力しないでください。「SCEP サーバーの URL」に複数の URL を入力できるのは負荷分散のためで、1つのプロファイルから発行される証明書は1枚です^[14]。

信頼された証明書プロファイル

Intune 管理センターの「デバイス」>「デバイスの管理」>「構成」で「作成」を選択し、プラットフォームに「Windows 10 以降」、プロファイルの種類に「テンプレート」を選択して、テンプレートの「信頼された証明書」を選択します。

手順2でダウンロードした2つの CA 証明書について、次の値でプロファイルを1つずつ作成します。

作成したプロファイルは、一覧でプラットフォームが「Windows 8.1 以降」と表示されます。これは Microsoft のドキュメントに記載された表示上の既知の問題で、プロファイルは Windows 10 と Windows 11 に適用されます^[15]。

SCEP 証明書プロファイル

同じ画面でテンプレートの「SCEP 証明書」を選択し、次の値で2つのプロファイルを作成します。

検証環境では、SCEP 証明書プロファイルもプラットフォームが「Windows 8.1 以降」と表示されました。

管理証明書の SCEP 証明書プロファイルは、証明書の種類を除いて過去の記事とほぼ同じ設定です。過去の記事では「ユーザー」にしていた証明書の種類を、本記事では「デバイス」にします（根拠は「管理証明書の配布単位」を参照）。

設定値の根拠

• 証明書の種類：2つとも「デバイス」にして、ローカルコンピューターの証明書ストアに配置します。センサーモードは利用者のサインインを待たずに端末を登録するため、端末単位の証明書を使用します。Okta の確認手順も、コンピューターレベルでの配布が前提です^[16]。管理証明書を「デバイス」にする理由は、次の「管理証明書の配布単位」で説明します。
• 割り当て：Okta の手順はユーザーグループへの割り当てですが、本記事ではデバイスグループに割り当てます。デバイスグループに割り当てた証明書は、利用者のサインインを待たず、端末の登録が完了してから配布されます^[14]。
• サブジェクト名：Okta に形式の要件はありません。Windows では を使用しないよう Microsoft が案内しているため、Microsoft Entra のデバイス ID を示す を使用します。2つの証明書の CN は同じ値になります。サブジェクト名に OU を追加したプロファイルも試しましたが、発行された証明書のサブジェクトは CN だけで、OU は含まれませんでした。2つの証明書は、デバイス証明書だけに含まれるカスタム拡張と、発行元の CA で見分けます（「動作の確認」のセクションを参照）。
• KSP：2つとも TPM を優先します。秘密鍵は TPM の中で作成され、端末の外に取り出せません。検証でも2つの証明書の秘密鍵は TPM（Microsoft Platform Crypto Provider）に格納され、アクセス権は SYSTEM と Administrators だけでした。利用者に権限を付与しないまま、端末の登録と管理対象の判定に成功しています。
• キー サイズ：Okta の手順どおり2048にします。検証では1024のまま配布したところ、Okta での発行が失敗しました。Windows で4096ビットを使用できるのはソフトウェア KSP だけで、TPM には格納できません^[14]。
• ルート証明書：SCEP サーバーの URL と同じ用途の CA の信頼された証明書プロファイルを指定します。端末は、SCEP サーバーから受け取った CA 証明書をここで指定した証明書と照合し、一致しない場合は証明書の要求が失敗します^[17]。
• 拡張キー使用法：2つとも「クライアント認証」だけを設定します。デバイス証明書の目印となるカスタム拡張（OID 1.3.6.1.4.1.51150.13.1）は Okta の CA が発行時に付けるため、Intune で設定する作業はありません。
• 有効期間：Okta の CA が発行する証明書の有効期間は1年です^[18]。

管理証明書の配布単位

管理証明書は、Okta の手順では証明書の種類が「ユーザー」ですが、共用端末では「デバイス」にします。Okta のナレッジベースでは、ユーザーとして配布する手順のまま共用端末に配布すると、最初にサインインしたユーザーだけが管理証明書を受け取り、ほかのユーザーは管理対象と判定されないと説明されています^[19]。検証では、「デバイス」で配布した管理証明書で、Windows の利用者を切り替えても管理対象と判定されました。

同じナレッジベースでは、マシンストアに配布した管理証明書の秘密鍵に、利用者の読み取り権限を手動で付与する手順が案内されています。検証（Okta Verify 7.2 の早期版のセンサーモード）では、権限を付与しなくても管理対象と判定されました。利用者のプロセスからは秘密鍵を開けないため、管理証明の署名は、利用者のセッションではなく Okta Verify のサービスで行われていると考えられます。

管理証明書は、管理対象であることを示すデータの署名にだけ使用され、ユーザーの認証には使用されません^[5]。Okta は証明書を端末に適用し、Okta のユーザーには結び付けないため^[20]、端末の利用者全員で1つの証明書を使用できます。

既存のユーザー証明書の除外

個人用端末に向けて、管理証明書を証明書の種類「ユーザー」で配布している場合は、そのプロファイルから共用端末を除外します。Okta Verify は同じ発行者の証明書についてユーザーストアを優先するため^[5]、ユーザー証明書があると共用端末の管理証明書が使用されません。ユーザーグループに割り当てたポリシーからデバイスグループを除外する構成は Intune でサポートされていないため^[21]、割り当てフィルターで除外します。次の例は、共用端末用の Windows Autopilot プロファイル名で端末を識別するフィルターです。

(device.enrollmentProfileName -eq "AP-Shared")

手順4：Okta Verify の配布

Okta Verify for Windows 7.2 以降を、センサーモードのオプションを付けて Intune から Win32 アプリとして配布します。

インストールコマンドのオプション

センサーモードでは、Okta Verify のインストーラーに次のオプションを指定します^[22]。

Okta の手順は、共用端末では EnrollmentOptions を Disabled にし、FastPass に端末を登録する予定の場合は Enabled にするよう案内しています^[2]。本記事では利用者に FastPass を登録させないため、Disabled にします。Disabled は認証時に登録を求めない設定で、利用者がアプリを開いて自分のアカウントを追加することはできます。

インストールコマンドは次のとおりです。/q は、インストーラーをサイレントモードで実行するオプションです^[23]。

OktaVerifySetup-x.x.x.x-yyyyyyy.exe /q AutoRegistration=DEVICE OrgUrl=https://<org>.okta.com EnrollmentOptions=Disabled

Okta Verify には、共有デバイス向けの AuthenticatorOperationMode=Shared もあります。これは NFC バッジのタップと PIN で認証する現場作業員向けの設定で、ユーザー固有の FastPass のフローが端末で許可されなくなります^[22]。センサーモードとは別の設定のため、本記事では指定せず、既定の Normal のままにします。

Win32 アプリの登録

Okta の手順に沿って、Okta Verify を Win32 アプリとして Intune に登録します^[23]。

1. Okta Admin Console の「設定」>「ダウンロード」で、Okta Verify for Windows (.exe) をダウンロードします。バージョンが 7.2 以降であることを確認します。7.2 以降が一般提供されていない org では、「早期アクセスのダウンロード」から取得します（「前提」のセクションを参照）。
2. Microsoft Win32 Content Prep Tool で、インストーラーを .intunewin 形式に変換します^[24]。
3. Intune 管理センターの「アプリ」>「すべてのアプリ」で「作成」を選択し、アプリの種類に「Windows アプリ (Win32)」を選択します。
4. 変換した .intunewin ファイルを選択し、次の値でアプリを作成します^[25]。

Okta の手順の検出規則は、OktaVerify.exe の有無だけを確認します。すでに Okta Verify がインストールされている端末ではインストール済みと判定され、センサーモードのオプションを付けたインストールは実行されません。この場合は、先に既存の Okta Verify をアンインストールします。Okta のドキュメントでも、動作モードなどの構成オプションを配布後に変更する場合は、アンインストールして別のオプションで再インストールするよう案内されています^[22]。

手順5：認証ポリシーの作成

Okta のドキュメントでは、センサーモードで登録した端末について、利用者が Okta FastPass を登録していなくても、認証時にデバイス保証ポリシーを適用できると説明しています^[2]。Okta の手順に沿って、デバイス保証ポリシーと、「登録済み」と「管理対象」を条件にするアプリサインインポリシーを作成します^[4]。

デバイス保証ポリシー

1. Okta Admin Console の「セキュリティ」>「デバイス保証ポリシー」で、「ポリシーを追加」を選択します。
2. プラットフォームに Windows を、「デバイス属性プロバイダー」に Okta Verify を選択し、条件を設定します。Windows では、OS バージョン、ディスク暗号化、トラステッドプラットフォームモジュール (Trusted Platform Module) などを条件にできます^[26]。
3. 「保存」を選択します。

センサーモードで登録した端末でも、条件に使う OS のバージョン、TPM、ディスク暗号化の値は、Okta Admin Console の端末の詳細で確認できます（「動作の確認」のセクションを参照）。検証では、ディスク暗号化と TPM を必須にしたポリシー（OS のバージョンは任意、画面ロックは条件にしない）で、FastPass を登録していない利用者のサインインがルールに一致しました。

アプリサインインポリシー

デバイス保証ポリシーをルールの条件にするには、org で Okta FastPass が有効になっている必要があります^[27]。このルールでは FastPass を認証に使いませんが、org の FastPass は有効にしたままにします。「セキュリティ」>「認証ポリシー」>「アプリサインイン」で「ポリシーを作成」を選択し、キャッチオールルールのアクセスを「拒否」にしてから、次のルールを追加します。

作成したポリシーは、共用端末から使用するアプリに割り当てます。Okta の手順では、ポリシーを Okta End-User Dashboard に割り当て、同じ端末で2人の利用者がアクセスできることを確認します。

設定値の根拠

• キャッチオールルール：「拒否」にします。ルールの条件を満たさないサインインは拒否されるため、検証の結果が分かりやすくなります。Okta のドキュメントでも、デバイスのシグナルを確実に収集するために「拒否」にするよう案内されています^[27]。
• デバイス管理：「登録済み」は、利用者が Okta Verify でアカウントを設定した端末でも満たされます^[1]。会社が管理する共用端末に限定するため、Okta の手順の例と同じく「管理対象」も条件にします。管理対象の判定には、手順3で配布した管理証明書を使用します。
• 認証要素：利用者は共用端末で Okta Verify を登録しないため、FastPass では認証できません。Okta の手順の例と同じく FastPass 以外の要素で認証するよう、「認証方法」で Okta Verify - FastPass を除外します。

動作の確認

手順1から手順5の設定の後、共用端末で証明書の配置、端末の登録、サインインを確認します。検証では、デバイス証明書の発行から1分以内に、利用者のサインインなしで端末が Okta に登録されました。

証明書の配置

Intune から配布された設定は、端末の「設定」>「アカウント」>「職場または学校にアクセスする」で接続を選択し、「情報」>「同期」を選択すると、定期的な同期を待たずに取得できます^[28]。

「コンピューター証明書の管理」（certlm.msc）で、次の点を確認します。

• 「中間証明機関」>「証明書」に、2つの Okta の CA 証明書が配置されています。
• 「個人」>「証明書」に、発行者が「Organization Intermediate Authority」の証明書が2つ配置されています。同じ場所にある Microsoft Entra 参加や Intune の証明書とは、「発行者」で見分けます。
• 証明書の「全般」タブに、「この証明書に対応する秘密キーを持っています。」と表示されます。
• デバイス証明書の「詳細」タブに、1.3.6.1.4.1.51150.13.1 の拡張があります^[16]。管理証明書にはありません。

「全般」タブには「情報不足のため、この証明書を検証できません。」と表示されます。Okta の手順で配布するのは中間 CA の証明書だけで、上位のルート CA の証明書が端末にないためです。検証では、この表示のままセンサーモードの登録と管理対象の判定に成功しました。

2つの証明書は、「発行先」がどちらもデバイス ID になり、「発行者」の名前も同じです。発行元の CA は、「詳細」タブの「機関キー識別子」で見分けます。機関キー識別子は発行元の CA の鍵を識別する値で、2つの証明書で異なります。検証環境では、デバイス証明書の機関キー識別子の先頭が、手順2で生成したデバイス証明書の SCEP URL の /pki/ に続く文字列と一致しました。

配布できない場合の確認箇所

証明書が配置されない場合は、端末のイベントログ、Okta のシステムログ、設定値の順に確認します。

端末では、イベントビューアーの「アプリケーションとサービス ログ」>「Microsoft」>「Windows」>「DeviceManagement-Enterprise-Diagnostics-Provider」>「Admin」に、SCEP 証明書プロファイルごとに次のイベントが記録されます^[29][30]。

Okta のシステムログには、証明書ごとの発行結果が記録されます（eventType：pki.cert.issue、表示名：Issue client certificate）。発行に失敗した場合の理由は「Error while issuing a ClientCertificate via delegated SCEP」とだけ表示されるため、次の設定を確認します。

端末の登録の確認

Okta のドキュメントでは、Okta Verify の画面、Okta Admin Console の端末の詳細、システムログで端末の登録を確認します^[33]。

Okta Verify を開くと、「アカウント」画面に、端末の名前（検証では SURFACE_LAPTOP2）と org の URL のエントリが表示されます。通常の Okta Verify では、利用者が登録したユーザーのアカウントが表示される画面です。センサーモードでは、ユーザーのアカウントではなく、端末そのものが登録されていることが分かります。

エントリを選択すると、「このデバイスはOktaに登録されています」と表示されます。センサーモードで登録した端末は、利用者が登録を解除できません^[2]。

Okta Admin Console の「ディレクトリ」>「デバイス」で端末を選択すると、端末の詳細が表示されます。「デバイスユーザー」には「このデバイスに登録されているユーザーはいません」と表示され、「デバイスのセキュリティ信号」と「デバイス識別子」には値が表示されます。

システムログには、次のイベントが記録されます。ドキュメントには「Bind client certificate」と「Create device enrollment」と記載されていますが、検証環境での表示名は次のとおりでした。

システムログの検索欄に eventType eq "pki.cert.bind" のように入力すると、対象のイベントだけを表示できます。

管理証明書の pki.cert.bind は、端末の登録時ではなく、端末からの最初のサインインのときに記録されました。管理証明書の結び付きを確認する場合は、サインインの前後のシステムログを確認します。

サインインの確認

手順5のポリシーを割り当てたアプリに、共用端末のブラウザーから、FastPass を登録していない利用者でサインインします。続けて Windows のサインインを別の利用者に切り替え、同じアプリにサインインします。システムログのポリシーの評価のイベント（policy.evaluate_sign_on）で、手順5のルールが適用されたことを確認します。検証では、どちらのサインインでも手順5のルールが適用され、パスワードとメールで認証できました。Windows の利用者を切り替えても、同じ端末として判定されました。

確認結果

運用上の注意

運用時は、証明書の更新、使用されない証明書の失効、クライアントシークレットの期限、端末の削除に注意が必要です。

証明書の更新

Okta の CA は更新リクエストをサポートしないため、証明書の有効期限が切れる前にプロファイルを再配布して証明書を交換します^[10]。Intune では SCEP 証明書プロファイルの更新しきい値がこの再配布にあたり、Okta のナレッジベースでも更新しきい値を設定するよう案内しています^[35]。更新しきい値を20%にすると、有効期間の80%が経過した時点で、端末が新しい証明書の取得を試みます^[14]。

Okta は、センサーモードの登録時に端末とデバイス証明書を結び付けます（pki.cert.bind）。検証では、Okta Verify を入れ直した端末に新しいデバイス証明書を発行すると、新しい証明書が同じ端末に結び付けられ、端末の登録が維持されました。発行し直した管理証明書も、次のサインインで端末に結び付けられました。更新しきい値による再発行の後の動作は、本記事では確認していません。

使用されない証明書の失効

Okta は、発行されたものの、成功した認証で90日以内に使用されなかった証明書を取り消します^[10]。センサーモードの登録がこの「使用」に含まれるかは、ドキュメントに記載がありません。検証では、管理証明書は端末からの最初のサインインのときに端末に結び付けられました。キッティング後に保管する予備の共用端末では、使用を始める前に証明書が失効する可能性があります。失効した場合は、「端末の削除と再利用」で説明する方法で、端末から証明書を削除して Intune と同期し、発行し直します。

クライアントシークレットの期限

手順1のクライアントシークレットの期限が切れると、新しい端末への証明書の発行と、更新しきい値による再発行が失敗します。期限が切れる前に、Microsoft Entra 管理センターで新しいシークレットを作成し、Okta の2つの SCEP 構成に入力します。Okta のナレッジベースでは、あわせて新しい SCEP URL を Intune の SCEP 証明書プロファイルに設定するよう案内されています^[32]。古いシークレットは、証明書が発行されることを確認してから削除します。

端末の削除と再利用

センサーモードで登録した端末は、利用者が Okta Verify から登録を解除できません。端末を廃棄する場合や別の用途で再利用する場合は、管理者が Okta Admin Console の「ディレクトリ」>「デバイス」で端末を非アクティブ化してから削除します。非アクティブ化すると、デスクトップの端末ではデバイス証明書が取り消されます^[36]。

検証時のシステムログでは、端末に結び付いていたデバイス証明書と管理証明書が、すべて一時停止として記録されました（pki.cert.lifecycle.suspend）。同じ端末を再び使用する場合は、端末の2つの証明書を削除してから新しい証明書を配布します^[10]。手順は次のとおりです。

1. Okta Admin Console で、端末を非アクティブ化してから削除します。
2. 端末の certlm.msc の「個人」>「証明書」で、発行者が「Organization Intermediate Authority」の2つの証明書を削除します。発行先が同じ Microsoft Entra 参加の証明書（発行者：MS-Organization-Access）は削除しないでください。
3. 端末で Intune と同期し、新しい2つの証明書が発行されたことを、Okta のシステムログの pki.cert.issue で確認します。
4. Okta Verify を起動し直します。検証では、Okta Verify を入れ直してから起動しました。システムログに device.enrollment.create、device.lifecycle.activate、pki.cert.bind が記録されれば、新しい端末として登録されています。

管理証明書も発行し直すのは、Okta が最初の認証で端末と管理証明書を結び付け、別の端末からその証明書で管理証明を行うと失敗するためです^[5]。検証で、デバイス証明書だけを発行し直したときは、登録し直した端末は「登録済み」になりましたが、「管理対象」とは判定されませんでした。管理証明書も発行し直すと、次のサインインで新しい証明書が端末に結び付けられ（pki.cert.bind）、「管理対象」と判定されました。

古いデバイス証明書のままでは、登録し直せません。検証では、端末を削除した後の Okta Verify の要求が失敗しました（app.oauth2.token.grant、理由：invalid_token）。

端末を削除せずに Okta Verify を入れ直した場合も、使用済みのデバイス証明書では登録できませんでした（device.enrollment.create、理由：Certificate has already been used to register this device, please deploy a new one）。この場合は、デバイス証明書（「詳細」タブに 1.3.6.1.4.1.51150.13.1 の拡張がある証明書）だけを削除して Intune と同期します。検証では、新しい証明書が既存の端末に結び付けられました。

おわりに

今回の検証では、センサーモードと管理証明書を組み合わせ、利用者に Okta Verify を登録させずに、共用 Windows 端末を「登録済み」「管理対象」の端末として判定できました。

Okta では、端末に関する機能の追加が続いています。2026年に入ってからも、デバイス保証の猶予期間や、デバイス保証の動的 OS バージョンコンプライアンスなどが一般提供されました^[37]。本記事の構成に関係するものでは、次の機能が早期アクセスや Preview の org で提供されています。

• 単一の証明書発行者：1つの CA を、デバイスアクセスや管理証明などの複数の用途で信頼できます。Preview の org で提供されており、Okta Verify for Windows 7.2 以降が必要です^[9]。本記事で用途ごとに使用した2つの CA を、1つにまとめられる可能性があります。
• 登録時に管理対象条件を適用する：Okta アカウント管理ポリシー (Okta account management policy) のデバイス条件で、Okta Verify の登録を「管理対象」の端末に限定できます（早期アクセス）^[38]。本記事では FastPass を使用しませんが、共用端末で FastPass も使う場合に、登録できる端末を絞り込めます。
• デバイスの可視性：Okta Admin Console の端末の詳細が、「アカウント」「構成」「シグナル」「識別子」の4つのタブで表示されます（早期アクセス）^[39]。今回の検証では有効にしていないため、センサーモードの端末がどのように表示されるのかは確認していません。

センサーモードも早期アクセスの機能で、検証時点では Okta Verify 7.2 も Production の org で一般提供されていません。今後も、これらの機能を共用端末で試し、本記事の構成がどのように変わるのかを検証して紹介します。

参考ドキュメント

1. [1]デバイス登録（Okta）
2. [2]デバイスポスチャセンサーモード（Okta）
3. [3]Zero Trust at the device layer: Silent Okta Verify deployment at scale（Okta ブログ）
4. [4]登録済みデバイスポリシーを作成して適用する（Okta）
5. [5]管理証明に関するよくある質問（Okta）
6. [6]Windows の MDM 自動登録を有効にする（Microsoft）
7. [7]WindowsのOkta Verify（Okta リリースノート）
8. [8]Okta Verify for Windows release notes（Okta リリースノート、英語版）
9. [9]単一の証明書発行者（Okta）
10. [10]認証局を構成する（Okta）
11. [11]Microsoft Entra ID でアプリの資格情報を追加および管理する（Microsoft）
12. [12]Microsoft IntuneでのWindows向け委任SCEP（Okta）
13. [13]Microsoft IntuneでWindowsの委任SCEPチャレンジを使用するCAとしてOktaを構成する（Okta）
14. [14]Intune で SCEP 証明書プロファイルを作成して割り当てる（Microsoft）
15. [15]Microsoft Intune で信頼された証明書プロファイルを作成する（Microsoft）
16. [16]証明書のデプロイメントを検証する（Okta）
17. [17]ClientCertificateInstall CSP（Microsoft）
18. [18]Preventing Jamf Pro Expired Certificates in Okta（Okta ナレッジベース）
19. [19]Deploying Device Management in OIE to Shared Workstations（Okta ナレッジベース）
20. [20]About Okta Device Trust With Delegated SCEP (Certificate) via Intune（Okta ナレッジベース）
21. [21]Microsoft Intune でポリシーを割り当てる（Microsoft）
22. [22]Windowsデバイス向けのOkta Verify構成（Okta）
23. [23]Okta VerifyをWindowsデバイスにデプロイする（Okta）
24. [24]アップロード用に Win32 アプリのコンテンツを準備する（Microsoft）
25. [25]Microsoft Intune での Win32 アプリの追加、割り当て、監視（Microsoft）
26. [26]デバイス保証ポリシーを追加する（Okta）
27. [27]デバイス保証をアプリサインインポリシーに追加する（Okta）
28. [28]Windows デバイスの MDM 登録（Microsoft）
29. [29]Microsoft Intune を使用したデバイスへの簡易証明書登録プロトコル (SCEP) 証明書プロファイルの展開のトラブルシューティング（Microsoft）
30. [30]Verifying if the Device Management SCEP Certificate Installed Successfully on Desktop OS（Okta ナレッジベース）
31. [31]Error While Issuing a ClientCertificate via Delegated SCEP（Okta ナレッジベース）
32. [32]Okta System Logs Showing the Error "FAILURE: Error while issuing a ClientCertificate via delegated SCEP"（Okta ナレッジベース）
33. [33]Okta Verifyでデバイス登録を確認する（Okta）
34. [34]RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)（IETF）
35. [35]Configure the Okta Identity Engine SCEP Profile for Client Certificate Renewal（Okta ナレッジベース）
36. [36]デバイスライフサイクル（Okta）
37. [37]Okta Identity Engineリリースノート(2026)（Okta リリースノート）
38. [38]登録時に管理対象条件を適用する（Okta）
39. [39]デバイスの詳細を表示する（Okta）