3行まとめ
- 米医療機器大手Strykerがサイバー攻撃を受け、報道によればMicrosoft Intuneの正規ワイプ機能が悪用され、数万台規模の端末が初期化されました。Strykerは、現時点でランサムウェアやマルウェアの兆候は確認されていないと公表しています
- CISAが全米企業に対しエンドポイント管理基盤の設定強化を緊急勧告しました。CISA告知とMicrosoftの実装ガイダンスを整理すると、RBAC最小権限・フィッシング耐性MFA・Multi Admin Approvalの3つの優先対策に集約できます
- Intuneを導入済みの企業は「管理プレーンそのものが攻撃面になる」前提で、今すぐ設定を監査してください。加えて、ワイプされた場合の復旧手段としてエンドポイントバックアップの導入も検討が必要です
はじめに
2026年3月11日、米国の医療テクノロジー企業Stryker Corporationがサイバー攻撃を受け、Microsoft環境を中心にグローバルな障害が発生し、業務システムに広範な影響が生じました。Strykerは自社の公表（Customer Updates: Stryker Network Disruption）で「Microsoft環境のグローバルな障害」「ランサムウェアやマルウェアの兆候なし」としています。報道によれば、攻撃者はマルウェアではなくMicrosoft Intuneの正規ワイプ機能を用いて端末を大量に初期化したとされています。
ゼロトラストの文脈で「IDが新しい境界線」と繰り返し言われてきましたが、今回の事案はその延長線上にある「管理プレーンが最大の攻撃面になる」という現実を突きつけています。
本記事では、事案の整理（一次情報と報道ベースを明確に区別）、CISAの勧告とMicrosoftガイダンスに基づく優先対策、そして日本企業が企業規模別に何をすべきかを整理します。
何が起きたのか
一次情報で確認できていること
Stryker Corporationは、人工関節、手術用ナビゲーション、除細動器（LifePak）などを製造する、米国有数の医療機器メーカーです。以下は、Stryker公式発表およびCISA告知から確認できる事実です。
- 2026年3月11日、Strykerがサイバー攻撃を受け、Microsoft環境にグローバルな障害が発生しました（Stryker公式）
- Strykerは「ランサムウェアやマルウェアの兆候は現時点で確認していない」と公表しています（Stryker公式）
- 2026年3月18日、CISAが米国組織に対する攻撃を踏まえ、エンドポイント管理システムの設定強化を勧告しました（CISA Alert）。Reutersによれば、この動きはStryker事案を受けたものです
- CISAはFBIと連携して追加の脅威特定と緩和策の策定を進めています（CISA告知）
- Reutersによれば、受注処理・製造・出荷に影響が及んでいます
報道ベースの情報（一次情報では未確認）
以下は主にBleepingComputer、TechCrunch、The Recordなどの報道に基づく情報であり、Stryker公式やCISA告知では技術的詳細までは確認されていません。
- 報道によれば、攻撃者はStrykerの特権アカウントを侵害した後、新たなGlobal Administratorアカウントを作成し、Intuneの組み込みワイプコマンドを使って大規模な端末初期化を行ったとされています（BleepingComputer）
- ワイプされた端末数は報道により「約80,000台」（BleepingComputer）から「200,000台以上」（The Record）まで幅があります。Stryker公式は被害台数を公表していません
- 攻撃を主張したのはイラン系ハクティビストグループ「Handala」で、50TBのデータ窃取を主張していますが、BleepingComputerによれば調査側ではデータ流出の兆候を確認できていません
- Handalaは12PBのデータ削除も主張していますが、主要一次・準一次ソースでは十分に裏取りできていません
- 一部の従業員が個人デバイスにもIntuneをインストールしていたため、個人データまでワイプされたとSNSで報告されています（The Record）
マルウェア不使用の意味
ここで重要なのは、Strykerが少なくとも現時点で「ランサムウェアやマルウェアの兆候は確認していない」と公表している点です。つまり、破壊的な結果が、従来型マルウェアではなく管理基盤の正規機能の不正利用によって生じた可能性が高いということです。
EDR/XDR単体では、正規の管理操作と攻撃者による管理プレーン悪用を即時に見分けにくい構造があります。Intuneからのワイプコマンドはそもそも「正規の管理者が実行する正当な操作」として設計されているため、監査ログ、特権昇格の承認、複数管理者承認、条件付きアクセス、SIEM相関分析を組み合わせた統制がなければ、検知・封じ込めは困難です。
「マルウェア不使用でありながら、結果としてはワイパーと同等の破壊性を持つ」。これはLiving off the Land（環境寄生型）攻撃がエンドポイント管理基盤にまで拡張された事例であり、PowerShellやWMI悪用の延長線上にある新たな脅威フェーズと言えます。
被害の実態：患者安全への波及
Strykerの受注・製造・出荷が停止し、Reutersの報道によれば患者固有のカスタム手術器具に関する手術がリスケジュールされる事態にまで発展しました。グローバルの工場（米国・アイルランド・インドなど）に影響が波及しています。
これはITインシデントが直接的に患者の治療遅延という物理的被害につながった事例であり、医療サプライチェーンのサイバーレジリエンスという観点で極めて重大です。
CISAの緊急勧告とMicrosoft実装ガイダンスから見える3つの優先対策
2026年3月18日、CISAはアラートを公開し、エンドポイント管理システムの設定強化とMicrosoftのベストプラクティスの採用を全米企業に求めました。Reutersによれば、この動きはStryker事案を受けたものです。
一次ソース：CISA Alert（2026年3月18日付）
以下の「3つの優先対策」は、CISAやMicrosoftがそのまま「3本柱」として提示したものではありません。CISA告知の推奨事項とMicrosoft Learnの実装ガイダンスを整理し、優先度の高い論点として再構成したものです。Microsoft Learnでは、Intune/Entraの実装面として、RBAC、特権アクセス管理、Multi Admin Approvalなどの統制が個別に案内されており、本記事の3項目はそれらを運用上の優先順位として整理したものです。
対策1：最小権限のロール設計（RBAC）
何をすべきか： IntuneのRole-Based Access Control（RBAC）を使い、各管理者ロールに「日常業務で必要な最小限の権限」だけを付与します。
なぜ重要か： 報道が正しければ、今回の事案では攻撃者がGlobal Administrator権限を取得したことで、Intuneを含むテナント全体に対して極めて広範な操作権限を得た可能性があります。Global Adminはテナント全体の「神の権限」であり、Intuneに限らずEntra ID、Exchange、SharePoint、Teamsなど全サービスを支配できます。日常運用でGlobal Adminを使っている組織は、今すぐ運用を見直す必要があります。
具体的なアクション：
- 日常のIntune管理には「Intune Administrator」や「Helpdesk Operator」等のスコープされたロールを使用します
- Global Adminは緊急アクセス用（Break Glass）に限定し、通常は無効化またはPIMでJust-in-Time昇格とします。Microsoftは緊急アクセスアカウントを2つ以上作成し、Global Administratorロールを付与したうえで、Passkey（FIDO2）推奨・フィッシング耐性MFA必須・監査ログ監視を案内しています
- カスタムRBACロールを作成し、「ワイプ」「スクリプト展開」「アプリ配布」等の破壊的操作を含まないロールを標準運用ロールとします
- ロールのスコープ（対象ユーザーグループ・デバイスグループ）を限定し、全デバイスへの操作権を持つロールを最小化します
参考：Microsoft | Best practices for securing Microsoft Intune
参考：Microsoft | Manage emergency access admin accounts
対策2：フィッシング耐性MFAと特権アクセス管理
何をすべきか： 全ての特権アカウントにフィッシング耐性のあるMFA（FIDO2セキュリティキー、Passkey、Certificate-Based Authentication等）を強制します。Microsoft Entra IDの条件付きアクセス・リスクベースシグナル・特権アクセス制御を組み合わせて、Intuneの高権限操作への不正アクセスを遮断します。
なぜ重要か： 従来型のMFA（SMSやAuthenticatorのプッシュ通知）は、Adversary-in-the-Middle（AiTM）フィッシングやMFA疲労攻撃に対して脆弱であることが繰り返し実証されています。攻撃者が管理者のセッションを奪取してしまえば、MFAは通過済みの状態になるため、後続のIntune操作は何のチャレンジもなく実行できてしまいます。
具体的なアクション：
- Entra IDの条件付きアクセスポリシーで、以下を設定します
- 特権ロール保持者に対してフィッシング耐性MFA（Authentication Strength: Phishing-resistant MFA）を必須化
- 「高リスク」サインインに対するブロックまたは追加認証要求
- 準拠デバイスからのアクセスのみ許可（Compliant Device要件）
- Privileged Identity Management（PIM）を有効化し、Global Admin / Intune Adminは常時無効・申請時のみ時限付きで有効化するJust-in-Time方式にします
- PIMのアクティベーション時にもフィッシング耐性MFAを要求します
- 特権アクセス用デバイス（Privileged Access Devices、いわゆるPAW）の導入を検討してください。IntuneやEntraの管理画面に私物端末や通常のメール閲覧端末から直接アクセスする運用は、管理プレーン侵害時の被害を拡大させやすい構造です。条件付きアクセスで「準拠済み管理端末からのみ」Intune管理コンソールへのアクセスを許可する設計が望ましいです。Microsoftはこの戦略をゼロトラストの「明示的な検証・最小権限・侵害前提」に基づく特権アクセスソリューションとして位置づけています
参考：Microsoft | Plan a Privileged Identity Management deployment
参考：CISA | Implementing Phishing-Resistant MFA
参考：Microsoft | Deploying a privileged access solution
対策3：Multi Admin Approval（複数管理者承認）
何をすべきか： Microsoft IntuneのMulti Admin Approval（MAA）を有効化し、破壊的・高影響な操作には第二の管理者による承認を必須とします。
なぜ重要か： 報道ベースでは、今回の攻撃は単一の特権アカウントで全てが実行されたとされています。もしデバイスワイプ操作に第二の管理者による承認が必要であれば、数万台の一斉ワイプは実行できなかった可能性が高いです。これは「Four Eyes Principle（二人制）」のIT版であり、金融業界では当たり前のように適用されている統制です。
具体的なアクション：
- IntuneのAccess Policiesで、少なくとも以下の操作にMAAを設定します
- デバイスアクション（Wipe / Retire / Delete）
- スクリプトの展開
- アプリケーションの配布・削除
- RBACロールの作成・変更
- コンプライアンスポリシー・構成プロファイルの作成・変更
- 承認者ロールを運用者ロールと分離します（自己承認を禁止）
- 承認リクエストの通知をメール・Teams等で即時通知し、異常な操作を迅速に検知できる体制を整えます
参考：Microsoft | Use Access policies to implement Multi Admin Approval
Intune管理者が今すぐやるべきチェックリスト
上記3つの対策を踏まえ、Intune導入済み企業の管理者が優先的に確認すべき項目をチェックリスト形式でまとめます。
即時確認
- Entra IDでGlobal Adminロールが割り当てられているアカウントの棚卸し（常時有効なアカウントは何個あるか）
- Global Admin / Intune AdminがPIMによるJust-in-Time昇格になっているか
- 特権アカウントのMFA方式がフィッシング耐性（FIDO2 / Passkey）であるか（SMS・プッシュ通知のみではないか）
- IntuneのMulti Admin Approvalが有効化されているか
- デバイスワイプ操作がMAA対象に含まれているか
- 緊急アクセスアカウント（Break Glass）は2つ以上存在し、常用禁止・厳格な監査・利用時即時アラートが設定されているか
短期対応（1ヶ月以内）
- 日常運用ロールからデバイスワイプ権限を分離したカスタムRBACロールの作成
- 条件付きアクセスポリシーに「特権ロール＋フィッシング耐性MFA必須」ルールを追加
- BYOD端末へのIntuneポリシー見直し（後述の「BYOD端末のフルワイプ問題」参照）
- 緊急アクセスアカウントの使用に対するアラート設定（Azure Monitor / Microsoft Sentinel）
- Intuneの監査ログをSIEM連携し、大量ワイプ等の異常パターンの検知ルールを作成
中長期検討
- エンドポイント管理基盤（Intune）自体をゼロトラスト評価の対象に含めた全体アーキテクチャの再設計
- Intune管理操作のネットワーク制限（管理用デバイス / 管理用ネットワークからのみ操作可能にする条件付きアクセス）
- 特権アクセス用デバイス（PAW）の導入
- インシデント対応手順へのIntune乗っ取りシナリオの追加（ワイプコマンド発行時の封じ込め手順）
- エンドポイントバックアップソリューションの導入（後述）
BYOD端末のフルワイプ問題について
今回の事案で見過ごせないのが、報道によれば個人端末にIntuneのCompany Portalをインストールしていた従業員の個人データまでワイプされた点です。
Intuneには「Wipe（デバイス全体の初期化）」と「Retire（企業データのみの削除、個人データは保持）」の2種類があります。企業所有端末にはWipeが適切な場合がありますが、BYOD端末に対してはRetireまたはMAM（Mobile Application Management）ポリシー中心の設計に限定すべきです。
MicrosoftのIntune計画ガイドも、企業メールや文書利用だけならアプリ保護ポリシー（App Protection Policy）中心の構成を案内しています。BYOD端末にはデバイス登録そのものを必須にするのではなく、MAMで企業データのみを保護し、個人データと企業データの削除範囲を明確に分離する設計が望ましいです。
具体的には以下の方針を推奨します。
- Intuneのデバイス登録時に「Corporate-owned」と「Personal」を明確に分類する
- Personalデバイスに対してはWipe操作を実行不可とするRBAC設計にする
- 個人端末にはデバイス登録ではなくMAMポリシーのみを適用し、企業アプリ内のデータ保護に限定する
- 退職者対応やインシデント対応の手順にもWipe/Retireの使い分けを明記する
ワイプされた後の「復旧力」：エンドポイントバックアップという備え
なぜエンドポイントバックアップが必要か
ここまでの対策はすべて「ワイプされないようにする」ための予防策です。しかし今回のStryker事案は、予防策をすり抜けた場合に何が起きるかを如実に示しました。数万台の端末が一斉にワイプされた場合、エンドポイントのデータが復旧できなければ、業務停止は長期化します。
OneDriveやSharePointにデータがあるから大丈夫、と考える管理者もいるかもしれません。しかし、ローカルに保存された業務データ、デスクトップ上の一時ファイル、アプリケーションの設定・プロファイル情報など、クラウド同期対象外のデータは想像以上に多いものです。端末のワイプ後にOSを再インストールし、OneDriveの同期が完了するまでの間、ユーザーは業務を再開できません。
つまり、「予防」だけでなく「復旧」の両輪が必要ということです。
エンドポイントバックアップソリューションの選択肢
エンドポイントのデータ保護に特化した主要なSaaS型バックアップソリューションの代表例を整理します。以下は網羅的な比較ではなく、今回の論点に照らして代表的な公開情報を整理したものです。最終的な選定では、対応OS、保存先、認証方式、復旧時間目標、ライセンス条件を個別に確認してください。なお、これらの製品はIntuneとは別の管理コンソールと保護機構を持つため、設計次第ではIntune管理プレーン侵害時の復旧基盤として機能し得ます。認証連携や管理者権限の分離設計は、導入時に個別確認が必要です。
Druva Data Security Cloud（旧inSync）
- SaaS型（100%クラウドネイティブ、AWS基盤）でアプライアンス不要
- Windows / macOS / モバイルのエンドポイントバックアップに加え、M365（Exchange / OneDrive / SharePoint / Teams）、Google Workspaceのバックアップにも対応
- Windows端末向けに、Intune経由でinSync Clientを配布する公式手順が公開されています
- Entra ID / Oktaとの連携によるユーザープロビジョニング対応
- 異常なファイル変更を検知するランサムウェア検知機能、イミュータブルバックアップを標準提供
- eDiscovery・コンプライアンス機能も統合されており、法的ホールド対応が可能
CrashPlan
- SaaS型のエンドポイントバックアップに特化
- Windows / macOS / Linux対応
- 継続的・自動的なバックアップと、ユーザー自身によるセルフサービス復元を提供
- バックアップ先を自社クラウド / Azure / ローカル / サードパーティクラウドから選択可能
- 管理コンソールのUIがシンプルで、比較的少人数の情シスチームでも導入しやすい設計です
- M365バックアップにも対応
Veeam Data Platform
- オンプレミス / クラウドハイブリッドに強く、仮想環境（VMware / Hyper-V）のバックアップで実績が豊富
- Veeam Agent for Windows / macOSでエンドポイントバックアップにも対応
- ファイル単位を含む柔軟な復元オプションを提供し、Windows / macOSエンドポイントおよびMicrosoft Entra ID保護の選択肢を持ちます
- 大規模環境や複雑なインフラ構成でも選択肢になり得る製品です
バックアップソリューション選定のポイント
今回の事案を踏まえて重視すべき選定基準は以下のとおりです。
- 管理プレーンの独立性：Intuneが侵害されてもバックアップの管理コンソール・データストアが影響を受けないこと（認証基盤を共有している場合は、バックアップ管理の認証をEntra IDと分離するか、バックアップ管理者専用のフィッシング耐性MFA＋条件付きアクセスを設定します）
- イミュータブルバックアップ：攻撃者がバックアップデータ自体を削除・改ざんできないこと
- 復旧速度（RTO）：数万台規模のワイプが発生した場合に、どの程度の速度でユーザーがデータを復元できるか
- ユーザーセルフサービスリストア：IT部門の手を借りずに、ユーザー自身がファイルを復元できる機能があるか（大規模ワイプ時にIT部門に全リクエストが集中することを避けるため）
日本企業が企業規模別に取るべき対応
ここからは、日本国内でIntuneを利用している企業が何をすべきかを、企業規模別に整理します。以下は、CISAおよびMicrosoftの公開ガイダンスを踏まえつつ、日本企業の一般的な運用実態を想定して筆者が整理した実務上の優先順位です。
日本ではMicrosoft 365 E3/E5ライセンスとセットでIntuneを導入する企業が急増していますが、当社の経験では、Intuneの管理プレーンに対するセキュリティ設計が十分に行われていないケースが少なくありません。
中小企業（〜300名規模）
現実的な課題： 情シス担当が1〜3名程度で、セキュリティ専任者がいない場合が多いです。PIMや特権アクセス用デバイスの導入はリソース的にハードルが高いため、まずは既存ライセンスで実施できる対策から着手し、必要に応じて追加機能の導入を検討します。
最低限やるべきこと（優先度順）：
- Global Adminアカウントの棚卸しと削減。日常運用には「Intune Administrator」ロールを使い、Global Adminは2アカウント（緊急アクセス用含む）に限定します。これはライセンス追加なしで今すぐ実施できます
- 全管理者アカウントにフィッシング耐性MFAを強制。FIDO2セキュリティキー（YubiKeyなど）は1本あたり1万円程度の投資で導入可能です。Keeperなどのパスワード管理マネージャーでPasskeyを統合管理できる場合はこちらの方がすぐに対応できます。これらは少なくとも管理者アカウントには必須化してください
- IntuneのMulti Admin Approvalを有効化。デバイスワイプ操作を承認制にするだけで、単一アカウント侵害時の被害を大幅に限定できます。MAAの利用可否は契約SKUに依存するため、導入時にはMicrosoftの最新ライセンス情報で確認してください（MicrosoftはIntune Plan 2をIntune Plan 1のアドオンとして案内しており、Intune Suiteに含まれます）
- BYOD端末にはMAMポリシーのみ適用。デバイス登録ではなくアプリ保護ポリシーに限定し、フルワイプのリスクを排除します
- エンドポイントバックアップの導入検討。CrashPlanは管理コンソールがシンプルで比較的導入しやすく、Druvaもユーザーセルフサービスリストアに対応しており、IT部門の負荷軽減になります
中堅企業（300〜3,000名規模）
現実的な課題： 情シス・セキュリティチームは存在しますが、Entra IDの特権管理やIntuneのRBAC設計を専門的に運用できる人材が限られている場合があります。
上記に加えてやるべきこと：
- PIM（Privileged Identity Management）の導入。Global Admin / Intune AdminのJust-in-Time昇格を実装します。一般にEntra ID P2相当機能が必要で、代表的にはMicrosoft 365 E5系で利用できます。実際の利用可否は契約SKUで確認してください
- カスタムRBACロールの設計。デバイスワイプ・スクリプト展開・アプリ配布を含まない日常運用ロールと、これらを含む特権操作ロールを分離します
- 条件付きアクセスの強化。特権ロール保持者に対して、準拠デバイスからのアクセス限定＋フィッシング耐性MFA必須のポリシーを構成します
- Intune監査ログのSIEM連携。Microsoft SentinelまたはサードパーティSIEMにIntuneの監査ログを転送し、大量ワイプ・大量ポリシー変更等の異常パターンの検知ルールを作成します
- エンドポイントバックアップの全社導入。DruvaはM365バックアップとエンドポイントバックアップを統合管理できます。ランサムウェア検知機能も標準搭載されているため、ワイプだけでなく暗号化攻撃への復旧手段にもなります
大企業（3,000名以上）
現実的な課題： 多拠点・グローバル展開で、Intune管理者が複数存在します。管理プレーンの統制が組織的に設計されていないと、今回のStryker事案と同様の被害規模になり得ます。
上記に加えてやるべきこと：
- 特権アクセス用デバイス（PAW）の導入。Intune / Entraの管理コンソールへのアクセスを、通常業務端末とは分離された専用端末に限定します。条件付きアクセスで「特定のデバイスコンプライアンスポリシーを満たす端末からのみ」管理コンソールへのアクセスを許可してください
- Intune管理操作のネットワーク制限。条件付きアクセスのネームドロケーション機能を使い、管理操作を特定のネットワーク（社内管理ネットワーク、VPN経由等）からのみ許可します
- インシデント対応手順の整備。「Intuneの管理プレーンが乗っ取られた場合」を想定したプレイブックを作成します。具体的には、Global Admin侵害検知時のテナントロックダウン手順、ワイプコマンドの緊急停止手順（Intuneの管理操作を条件付きアクセスで即時ブロック）、復旧手順（バックアップからのリストア優先順位）を定義します
- Entra ID設定のバックアップ。VeeamはEntra IDのオブジェクト（ユーザー、グループ、ロール、アプリケーション等）のバックアップに対応しています。Intuneのポリシー設定自体も定期的にエクスポート・バージョン管理しておくことで、侵害後の再構成を迅速化できます
- サプライチェーン全体の管理プレーンリスク評価。自社だけでなく、Intune管理を委託しているMSPや関連会社のアクセス権限・MFA強度も監査対象としてください
おわりに：管理プレーンのゼロトラスト
シンジがゼロトラストの話をするとき、「IDが新しい境界線」という話をよくします。しかし今回のStryker事案は、その先にある「管理プレーンが最大の攻撃面になる」という現実を示しました。
EDRを入れていても、Intuneからの正規ワイプコマンドの悪用は、単体では見分けることはかなり難しいと思います。ファイアウォールを強化しても、クラウド上の管理コンソールへの正規セッションは通過します。つまり、管理プレーンそのものに対するゼロトラスト、すなわち最小権限・継続的検証・明示的な承認を適用しなければ、苦労してお金をかけて導入した正規ツールが、攻撃者にとって最大の武器に変わるということです。
そして、どれだけ予防策を積み上げても侵害される可能性はゼロにはなりません。だからこそ、ワイプされた後に復旧できるエンドポイントバックアップという「最後の砦」を用意しておくことが、BCPの観点で不可欠です。
Intuneを導入している組織は、CISAのアラートとMicrosoftのベストプラクティスを今すぐ確認し、設定の監査を実施してください。
参考リンク（公開情報）
- Stryker | Customer Updates: Stryker Network Disruption（2026年3月）
- CISA Alert: CISA Urges Endpoint Management System Hardening After Cyberattack Against US Organization（2026年3月18日）
- Reuters | US agency asks companies to secure Microsoft tool after Stryker cyberattack（2026年3月19日）
- Reuters | Stryker says cyberattack on its network contained（2026年3月17日）
- Microsoft | Best practices for securing Microsoft Intune
- Microsoft | Use Multi Admin Approval in Intune
- Microsoft | Plan a Privileged Identity Management deployment
- Microsoft | Manage emergency access admin accounts
- Microsoft | Deploying a privileged access solution
- Microsoft | Intune Planning Guide
- Microsoft | Remote Device Action: Wipe
- Microsoft | Microsoft Intune Plans and Pricing
- CISA | Implementing Phishing-Resistant MFA
- BleepingComputer | CISA warns businesses to secure Microsoft Intune systems after Stryker breach
- BleepingComputer | Stryker attack wiped tens of thousands of devices, no malware needed
- The Record | FBI, CISA warn on Microsoft Intune risks after Iran-linked cyberattack on Stryker
- Druva | Endpoint Data Backup and Restore
- Druva | How to deploy inSync Clients using Microsoft Intune
- CrashPlan | Endpoint Backup Solutions
- CrashPlan | Microsoft 365 Backup and Recovery
- Veeam | Veeam Agent for Microsoft Windows
- Veeam | Microsoft Entra ID Backup & Recovery
