What Is Intel AMT? Secure Deployment, Disablement, and Deprovisioning

Intel Active Management Technology (Intel AMT) is an out-of-band management capability on supported commercial platforms. It can provide limited remote power, diagnosis, and redirection functions when the operating system is unavailable, but it is not generic remote-control software and cannot continue working after both power and the management network are disconnected.

This capability sits outside the operating system's security boundary. Configure it only when the device owner has explicitly authorized it, the enterprise has a genuine operational need, and certificates, network isolation, firmware updates, logs, and retirement processes are ready. Never expose an AMT management interface directly to the public internet, and do not enable it yourself on a managed device.

Table of Contents

Quick conclusions

Intel AMT, Intel vPro, Intel Management Engine or CSME, MEBx, and operating-system agents are not the same thing.
Out-of-band does not mean “unconditionally online.” The device still needs standby power, a supported and configured network path, completed provisioning, and a compatible management endpoint.
KVM, SOL, IDER or USB Redirection capabilities vary by model, SKU, AMT and firmware version, network type, provisioning mode, and user-consent policy.
A production deployment should enforce TLS, unique strong credentials, least privilege, certificate lifecycle controls, a dedicated management network, source allowlists, continuous logging, and updates.
Leave AMT unprovisioned when it is not needed. When a device is transferred, retired, or removed from management, complete and verify deprovisioning rather than merely deleting its OS agent.

Distinguish six concepts first

Concept	What it is	What it is not
Intel vPro	A commercial-platform capability brand whose features depend on the platform, processor, firmware, and OEM implementation	Seeing an Intel CPU does not automatically provide every AMT feature
Intel AMT	A firmware-provided out-of-band management capability on explicitly supported platforms	It is not ordinary desktop remote-control software or a patching or EDR product
Intel ME or Intel CSME	The platform management and security firmware subsystem; AMT functionality resides there on supported systems	It does not mean AMT is provisioned; disabling AMT does not remove CSME
MEBx	An OEM-provided local firmware configuration interface or entry point whose name and access method vary by model	It is not a remote management server or an operating-system application
Management console	An authorized enterprise service that provisions and invokes AMT, such as a currently supported management platform	It should not be a browser connecting to a device directly from an arbitrary internet address
Operating-system agent	An in-band service that manages software, policy, and telemetry from inside the system	Removing or reinstalling it does not automatically erase AMT settings in firmware

Intel's introduction to AMT describes the relationship among AMT, vPro, CSME, network hardware, and provisioning services. Assess capability from the combined inventory of the exact OEM model, SKU, firmware, and management platform, not merely a sticker or a similar-sounding BIOS entry.

An out-of-band path still has prerequisites

An out-of-band path reaches AMT firmware from a management console over a controlled network and does not require the target OS to boot successfully. An in-band path requires a working OS and agent. The two can complement one another: AMT might wake a device, after which a supported endpoint platform installs patches once the OS starts. AMT does not magically modify OS files while the machine is off.

Remote reachability also requires sufficient standby power, a supported onboard network interface, AMT provisioned according to organizational policy, correct addressing, naming, certificates, routing, and firewall rules, plus version compatibility between the management endpoint and device. The capability is unavailable when power is removed, the relevant network path is disabled, or hardware does not support a given power state. Wireless and remote-access behavior cannot be inferred from a wired, powered-on test either.

Detect capabilities per device

Capability	Use boundary	Verify before use
Remote power	Power on, shut down, or restart in supported power states	Standby power, OEM power-state support, authorization, and maintenance window
Hardware inventory and events	Read exposed platform asset, health, or event data	Data fields, privacy purpose, retention, and accuracy; do not treat it as a complete CMDB
KVM	Remotely view and potentially control keyboard, video, and mouse	SKU and firmware support, display limits, user consent, session indication, and audit
SOL	Observe or control supported boot and console flows through a text serial session	Platform support, character interface, access role, and secure session
Storage Redirection, USB-R, or historical IDER	Present a controlled image to a device for diagnosis or recovery	Formats actually supported by the current release, consent policy, image integrity, and change approval
Remote boot and recovery	Select a supported boot target or recovery flow	Exact firmware, boot security, disk-encryption recovery key, and local rollback

Intel's feature catalog lists feature families but does not promise every feature on every machine. A management system should query capabilities actually reported by the device. Without detection and test evidence, a design must not promise KVM, SOL, IDER, wireless operation, or a particular powered-down state.

Responsibility boundaries for in-band and out-of-band

An in-band agent suits software distribution, configuration, telemetry, EDR, and user support while the OS works. Out-of-band AMT suits limited power, boot, hardware information, and recovery paths. It does not provide arbitrary file management and does not replace identity, patch management, backups, EDR, disk encryption, or on-site service.

The source compares AMT with Microsoft SMS and implies that AMT can directly distribute patches, manage files, and detect intrusions while a machine is off. That overstates the boundary. SMS is a historical product name, while the SDK, RDK, SCS, SOAP, and WSDL descriptions belong to the 2011 tooling ecosystem. Those download routes, sample credential assumptions, and interfaces are not a current deployment baseline.

Should it be enabled?

Proceed to design only if every answer is clearly yes: device ownership and user notice are appropriate; an operational need exists for management outside the OS; exact hardware and firmware remain supported; the organization owns a current compatible management platform; and PKI, secret custody, network isolation, logging, incident response, and retirement owners are ready.

Personal computers, devices outside centralized management, systems with unpatchable old firmware, and secondhand machines of unclear purpose should remain unprovisioned. An MEBx or AMT menu on an enterprise asset does not authorize a user to enable it. If a device appears provisioned by another organization, stop, preserve evidence, and contact the asset owner or authorized IT rather than resetting it or trying to gain control.

Predeployment inventory

Asset owner, business purpose, data classification, user notice, and approval-ticket number.
OEM, full model and SKU, processor platform, network adapter, BIOS, and exact Intel CSME and AMT versions.
Whether AMT exists and its enabled, provisioning, and control state; do not put serials, UUIDs, MAC addresses, or credentials in public records.
Device-reported power, KVM, SOL, storage-redirection, wired, and wireless capabilities plus user-consent behavior.
Current management platform, version, tenant, endpoint group, roles, service accounts, and named owner.
Network zone, permitted management sources, name resolution, time synchronization, remote-access path, and every relevant firewall rule.
TLS certificate chain, purpose, name, issuer, expiration, revocation checking, private-key custody, and rotation owner.
OEM firmware-update path, applicable Intel advisories, maintenance window, local recovery method, and complete deprovisioning path.

If any item cannot be confirmed, remain in discovery. Scanning and detection must also stay within written authorization; do not mass-search the internet or addresses the organization does not own for AMT.

Secure deployment checklist

Pilot on a few test devices and an isolated management network. Confirm local hands, backups, disk-encryption recovery keys, and the procedure for restoring firmware settings.
Use currently supported OEM firmware and a supported management platform. Check Intel advisories and OEM release notes first; obtain firmware only through system-manufacturer-approved channels.
Use an organization-approved provisioning mode and PKI. Enforce TLS and validate the certificate chain, device name, purpose, validity, and revocation status. Do not bypass validation for an unknown self-signed certificate.
Give every device a unique, random, sufficiently strong management credential, store it in an enterprise secret manager, and rotate it regularly. Never share a default, templated, or spreadsheet plaintext password.
Place AMT in a dedicated management zone and allow only management servers or controlled jump sources. Deny user, guest, and internet ingress by default. Use an audited enterprise tunnel or gateway for cross-site access.
Assign provisioning, remote-control, read-only audit, and deprovisioning roles with least privilege. Apply user consent, two-person approval, or a maintenance window to high-risk KVM, redirection, and boot actions, choosing whichever organizational policy is stricter.
Centrally log authentication failures, configuration, certificates, roles, remote power, KVM, SOL, redirection, firmware, and deprovisioning events. Protect personal identifiers and network data in logs.
Test in-band and out-of-band, powered-on and supported sleep states, certificate failure, rejected sources, user consent, alerts, logs, and local rollback against an acceptance sheet. Disable unapproved capabilities afterward.

Intel's AMT privacy statement lists asset, event, network, access-control, UUID, key, KVM password, TLS certificate, and wireless configuration data that firmware may store. Deployers must bring these data into notice, access, retention, export, and deletion policies.

TLS and the network boundary

Intel's non-TLS end-of-life notice explains how platform generations progressively removed unencrypted management connections. An older device supporting plaintext is not permission to keep using it; a newer device enforcing TLS is not permission to expose it to the internet.

Certificates must be issued or managed by an organization-approved trust system. Clients must fully validate server certificates, and the management side must verify device identity as designed. An expired certificate, name mismatch, unsynchronized time, or revocation-check failure should stop the connection rather than trigger a temporary validation bypass. Remote access should terminate at an enterprise management service with identity, authorization, and logging controls, never at a public port forward.

Operations and audit

Daily or according to risk, check management-service health, authentication anomalies, unknown devices, certificate expiry, and configuration drift.
Monthly or on each advisory cycle, review OEM firmware, Intel security advisories, management platform, and agent versions; record evidence for both applicable and non-applicable findings.
Regularly verify deny rules from approved networks and use the organization's external-asset inventory to confirm there is no public AMT exposure. Do not actively probe third-party addresses.
Rehearse local recovery, credential rotation, certificate renewal, administrator departure, management-platform failure, and full deprovisioning.
Every KVM, SOL, redirection, and remote-boot use should have a ticket, purpose, operator, user-consent status, start and end times, and result.
Retain only the minimum logs required for security, compliance, and failure analysis; restrict access and delete them on schedule.

Firmware and vulnerability response

Intel's AMT and CSME security-update index directs users to the latest system-manufacturer version that addresses the relevant issue. INTEL-SA-01427, published in August 2026, covers some AMT and Standard Manageability firmware and gives the same manufacturer-firmware recommendation. Match an advisory per device against chipset, firmware branch, and OEM package rather than comparing only a major version number.

CISA's current Known Exploited Vulnerabilities data feed contains the historical AMT vulnerability CVE-2017-5689, whose entry calls for applying updates according to vendor instructions. BOD 22-01 remediation deadlines bind U.S. Federal Civilian Executive Branch agencies; other organizations can use the catalog for risk prioritization without presenting it as a universal legal deadline. This also shows that “the device is old but still works” is not risk-acceptance evidence. If an affected device no longer receives fixes, isolate and deprovision it and set a replacement date rather than expanding AMT reachability.

Disablement, deprovisioning, and removal differ

Action	What it may accomplish	What must not be assumed
Delete a device from the console	Remove the object from one management platform	AMT configuration may remain in device firmware
Remove the OS agent or reinstall the OS	Remove the in-band management path	This does not automatically revoke AMT certificates, credentials, or network settings
Block the management network	Immediately reduce remote reachability	This is not permanent erasure; the configuration may become usable when the rule returns
Disable a feature in firmware	Turn off some behavior depending on the OEM and release	It may not fully deprovision AMT and does not mean disabling CSME
Full deprovisioning	Clear enterprise AMT configuration through a currently supported tool	Semantics depend on the tool and release; verify both locally and remotely

The current Intel EMA Administration and Usage Guide says full unprovisioning removes custom root certificate hashes and the PKI DNS suffix, and that a remote endpoint may later require physical access to reprovision in the corresponding mode. Confirm local hands and rollback before cutting the last remote recovery path.

Device exit and transfer checklist

Confirm the asset, authorized exit ticket, recipient, data-handling requirement, and local owner. Freeze new remote sessions.
Export a protected configuration summary, patch evidence, and audit logs with unnecessary identifiers removed. Do not export plaintext passwords or private keys.
First restrict the network to the minimum management source needed for deprovisioning, then perform full deprovisioning through the original provisioning instance and currently supported procedure.
Revoke or delete device certificates, rotate related secrets, and remove the asset from DNS, address reservations, allowlists, endpoint groups, jump-host permissions, and monitoring.
Have authorized local personnel confirm that firmware shows unprovisioned or the organization-required disabled state, then verify that the management path fails from both allowed and disallowed networks.
For a transfer, clear management configuration belonging to the prior organization under OEM guidance. Treat disk erasure, TPM handling, and BIOS restoration as separate approved data-destruction processes, not as part of AMT deprovisioning.
Update the CMDB, certificate register, vulnerability exceptions, and retirement record with verification evidence, date, and owner.

Suspected exposure or takeover

Immediately isolate the AMT path at the switch, router, firewall, or management gateway while preserving device power and evidence. Do not merely stop an OS agent.
Preserve management platform, identity, PKI, DNS, DHCP, VPN, jump host, firewall, and AMT event logs while keeping UUIDs, MAC addresses, certificates, and user data private.
From a trusted local or isolated path, confirm firmware, provisioning state, accounts, certificates, and actual capabilities, and check OEM and Intel advisories.
Rotate management credentials, service accounts, and relevant certificates; patch firmware and the management platform. If integrity is uncertain, fully deprovision and reprovision from the approved baseline.
Search for anomalous power, KVM, SOL, redirection, boot, and configuration activity, and assess possible impact to the OS, disk encryption, identity, and data.
Complete an incident review and correct the exposure source, allowlist, monitoring, and offboarding flow before restoring the minimum required management path.

Rollback and stop conditions

A deployment rollback should preserve the previous supported configuration, network rules, certificate register, device-capability snapshot, management-platform backup, and local recovery procedure. It must never revert to known-vulnerable firmware, plaintext protocols, or shared credentials. Rehearse on one device first and define a local stop point at every phase.

Stop enablement or change if any of these is true: there is no written authorization; ownership is unclear; the exact AMT or CSME version is unknown; firmware no longer receives fixes; management endpoint and device are incompatible; the only administrator credential or PKI private key is uncontrolled; TLS cannot be enforced; public port forwarding is required; there is no source allowlist; no local recovery person is available; a disk-encryption recovery key is unavailable; user consent cannot be logged; or the deprovisioning path is unverified.

How to treat the 2011 tool names

The source's SDK, RDK, SCS, SOAP, WSDL, and Microsoft SMS discussion reflects its era. Some names may still exist in later forms, but a 2011 package, interface, security default, or download address does not establish current support. In particular, do not search mirror sites for what the source called the “latest version.”

Start today with the exact hardware's OEM support page, current Intel documentation, and the selected management product's current guide. Confirm version, license, maintenance status, provisioning mode, and alternatives. When migrating an old console, inventory and pilot in parallel and prove that the new platform can deprovision old endpoints. Do not shut down the old platform first and strand firmware configuration on devices.

Official references

Archived 2011 source

The inert plain-text fence below preserves the complete visible body from source_export for provenance. It is not current operational guidance. The maintained layer corrects or moves to historical context its claims about loss of power, capability scope, Microsoft SMS, SDK, RDK, SCS, SOAP, WSDL, and download routes. The final http 91bjb attribution address cannot be established as a safe current source, so it remains only as plain-text provenance and is not a clickable link, recommendation, or endorsement. The source contains no personal data, credentials, or tracking parameters that require redaction and has no trailing whitespace; nothing was changed.

什么是INTEL AMT（英特尔 AMT),有什么功能

有些客户可能发现在Thinkpad的BIOS里面多出来一项INTEL AMT的选项,经过了解与探听,终于发现这个神秘的INTEL AMT组件是做什么东东的了.

Table of Contents

Toggle

- [这就是英特尔® 主动管理技术](https://blog.lazying.art/en/html/computer_internet/560/%e4%bb%80%e4%b9%88%e6%98%afintel-amt%ef%bc%88%e8%8b%b1%e7%89%b9%e5%b0%94-amt%e6%9c%89%e4%bb%80%e4%b9%88%e5%8a%9f%e8%83%bd.html/#%E8%BF%99%E5%B0%B1%E6%98%AF%E8%8B%B1%E7%89%B9%E5%B0%94%C2%AE_%E4%B8%BB%E5%8A%A8%E7%AE%A1%E7%90%86%E6%8A%80%E6%9C%AF)

  - [概述](https://blog.lazying.art/en/html/computer_internet/560/%e4%bb%80%e4%b9%88%e6%98%afintel-amt%ef%bc%88%e8%8b%b1%e7%89%b9%e5%b0%94-amt%e6%9c%89%e4%bb%80%e4%b9%88%e5%8a%9f%e8%83%bd.html/#%E6%A6%82%E8%BF%B0)
  - [SDK 支持低级英特尔® AMT 编程功能](https://blog.lazying.art/en/html/computer_internet/560/%e4%bb%80%e4%b9%88%e6%98%afintel-amt%ef%bc%88%e8%8b%b1%e7%89%b9%e5%b0%94-amt%e6%9c%89%e4%bb%80%e4%b9%88%e5%8a%9f%e8%83%bd.html/#SDK_%E6%94%AF%E6%8C%81%E4%BD%8E%E7%BA%A7%E8%8B%B1%E7%89%B9%E5%B0%94%C2%AE_AMT_%E7%BC%96%E7%A8%8B%E5%8A%9F%E8%83%BD)
  - [RDK 可提供高级英特尔® AMT 解决方案构建模块](https://blog.lazying.art/en/html/computer_internet/560/%e4%bb%80%e4%b9%88%e6%98%afintel-amt%ef%bc%88%e8%8b%b1%e7%89%b9%e5%b0%94-amt%e6%9c%89%e4%bb%80%e4%b9%88%e5%8a%9f%e8%83%bd.html/#RDK_%E5%8F%AF%E6%8F%90%E4%BE%9B%E9%AB%98%E7%BA%A7%E8%8B%B1%E7%89%B9%E5%B0%94%C2%AE_AMT_%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88%E6%9E%84%E5%BB%BA%E6%A8%A1%E5%9D%97)
  - [SCS 将英特尔® AMT 设备与企业的基础架构相连](https://blog.lazying.art/en/html/computer_internet/560/%e4%bb%80%e4%b9%88%e6%98%afintel-amt%ef%bc%88%e8%8b%b1%e7%89%b9%e5%b0%94-amt%e6%9c%89%e4%bb%80%e4%b9%88%e5%8a%9f%e8%83%bd.html/#SCS_%E5%B0%86%E8%8B%B1%E7%89%B9%E5%B0%94%C2%AE_AMT_%E8%AE%BE%E5%A4%87%E4%B8%8E%E4%BC%81%E4%B8%9A%E7%9A%84%E5%9F%BA%E7%A1%80%E6%9E%B6%E6%9E%84%E7%9B%B8%E8%BF%9E)
  - [结论](https://blog.lazying.art/en/html/computer_internet/560/%e4%bb%80%e4%b9%88%e6%98%afintel-amt%ef%bc%88%e8%8b%b1%e7%89%b9%e5%b0%94-amt%e6%9c%89%e4%bb%80%e4%b9%88%e5%8a%9f%e8%83%bd.html/#%E7%BB%93%E8%AE%BA)

# 这就是英特尔® 主动管理技术

为了帮助对英特尔® 主动管理技术（英特尔®AMT）提供丰富支持的软件解决方案进入市场，英特尔为软件开发人员提供了一组功能强大且可免费下载的工具，包括软件开发套件 (SDK)、参考设计套件 (RDK) 和设置与配置服务 (SCS)。通过提供应用编程接口(API)、库和样本代码，这些工具可帮助软件提供商将高质量的解决方案快速推向市场。

## 概述

英特尔® 主动管理技术（英特尔®AMT）是一组固件驻留的硬件功能，允许网络管理应用执行高级远程功能，即使目标设备已切断电源或其操作系统 (OS)已损坏也是如此。由于该技术能够帮助系统管理员远程管理系统，并最大程度地减少高成本现场服务，因此英特尔® AMT为客户带来了强大的优势。由于客户主要依赖软件实施来实现此项技术，因此英特尔为软件制造商提供了一组强大的工具，以便于将
 英特尔® AMT 集成到网络可管理性应用中：

* 英特尔® AMT 软件开发套件 (SDK) 提供低级编程功能，允许开发人员构建充分利用英特尔® AMT 的可管理性应用。
 * 英特尔® AMT 参考设计套件 (RDK) 包括一组可自定义的开放源代码软件构建模块，开发人员可利用这些模块快速构建英特尔® AMT 控制台应用。
 * 英特尔® AMT 设置与配置服务 (SCS) 借助一些凭据和参数，可自动完成英特尔® AMT 平台的移植任务，这使得用户可远程管理其系统。

本文档对每个工具集均进行了概括介绍，其中包括：各个工具集在开发流程中的价值、所含内容的详细说明，以及可从哪里获取更多信息。有关英特尔® AMT 技术的更多信息，请参阅英特尔® 可管理性开发商团体，其中包括：工具下载、技术文档、用户案例、论坛，以及特定软件合作伙伴机会等等。该站点上的架构指南 包含英特尔® AMT 的全面技术说明。

## SDK 支持低级英特尔® AMT 编程功能

借助英特尔® AMT SDK 提供的应用编程接口 (API)和样本代码，开发商可在其解决方案当中部署英特尔® AMT 功能，使其可在 Microsoft Windows* 或 Linux*之上运行®。借助这一组合，软件开发商可快速熟悉英特尔® AMT 在编程方面的要求，并能将功能强大的下一代网络管理解决方案推向市场。

SDK 库和 API 提供了一种对®非易失性存储（用于存储英特尔® AMT 数据）进行调用的抽象接口，用户辅之以“LAN之上的串行”和“IDE重定向”会话技术，就能对英特尔® AMT 设备进行远程管理。借助这一抽象接口，开发商可轻松实现关键的英特尔® AMT功能，而不必重新创建。基于简单对象访问协议 (SOAP) 的英特尔® AMT 网络接口在 SDK 中以 Web 服务描述语言 (WSDL)文件的形式提供，而样本代码可用来帮助指导软件开发商编写其自己的英特尔® AMT 应用。该 SDK 可使用包括 SOAP 堆栈在内的任何语言实现。

英特尔® 主动管理技术 SDK 入门指南 提供有关英特尔® AMT SDK 更全面的信息，其中包括：系统最低要求、如何配置英特尔® AMT 客户端，及如何使用样本代码。该 SDK 的最新版本可从英特尔® 主动管理技术软件开发套件下载页免费获得。

## RDK 可提供高级英特尔® AMT 解决方案构建模块

借助英特尔® AMT RDK，开发商能够快速构建简单、具有合便开销的英特尔®AMT 控制台解决方案。通过一组基于 Java*的软件构建模块，可达到上述目的（这些构建模块可从部分开发商处抽象出实现的细节，并使其它开发商无须了解实现细节即可部署该技术）。借助随构建模块一同提供的完整源代码，开发商可对其进行修改，从而可提供更复杂的定制功能。RDK 还包括一个简单的基于 GUI的实用程序，借助该程序，用户可进一步了解网络平台中的各项英特尔® AMT 功能。

RDK 由三个可分别下载的软件包组成，每个软件包为开发商提供一组完全不同的互联功能。

* RDK 实用应用软件包使开发商能够快速熟悉英特尔® AMT 平台的实际操作，从而能够远程收集硬件信息并执行管理功能。
 * RDK 构建模块软件包当中包括：执行各个英特尔® AMT 任务的 Java 二进制文件，以及指导开发商在其应用中使用这些二进制文件以快速部署管理功能的相关文档。
 * RDK 源代码软件包包括：用于构建模块的 Java 源代码及其关联构建脚本。开发商可使用该源代码定制构建模块，或将其移植为其他语言。

英特尔® AMT 参考设计套件技术概述 对所有三个下载软件包进行了更全面的介绍，对三者如何在开发组织中协同使用和单独使用、也进行了相应的介绍。每个 RDK 下载软件包的最新版本，可从英特尔® 主动管理技术参考设计套件下载页获得。

## SCS 将英特尔® AMT 设备与企业的基础架构相连

英特尔® AMT SCS 为 IT 部分提供了一种将英特尔® AMT 设备与目标企业进行连接的的方法。借助英特尔 SCS 提供的工具，软件制造商可在其产品中方便地实现该功能，从而为客户提升价值，并使其产品获得竞争优势。

SCS 的核心功能由一个 Windows 服务提供，该服务借助密码和其它凭证将 SOAP API 进行移植，使其能够与英特尔® AMT设备进行通信，进而能够与管理应用进行通信。它使用 SQL Server* 数据库（必须从英特尔 SCS单独安装）来存储与系统操作关联的配置数据、存储过程和日志。并提供有一个控制台应用示例（其中包括可以由软件公司在其产品中随意修改的全部源代码）。开发商既可以将此控制台应用作为用于创建自身控制台的参考应用，也可作为用来添加增值特性的基础应用。

英特尔® AMT 设置与配置服务技术概述对与英特尔® AMT SCS 关联的架构和功能进行了全面说明，其中包括：在企业内部进行部署的选项概述。英特尔® AMT SCS 的最新版本可从英特尔® 主动管理技术设置与配置服务下载页获得。

## 结论

英特尔工具可在开发商团队内部任意获得，支持在网络管理应用中快速部署英特尔 ®AMT 支持。英特尔® AMT SDK 可提供各种 API 及库，这些库有利于实现一些低级编程任务。英特尔® AMT RDK包括抽象和简化常见编程任务的软件构建模块，以及参考控制台实用应用。通过英特尔® AMT SCS，软件制造商能够轻松为其客户提供将英特尔®AMT 设备添加到受管网络的方法。

作为可下载软件包的一部分，系统还提供了有关这三个工具集的详尽文档。总而言之，借助这些工具，网络管理应用制造商能够非常轻松地将对英特尔® AMT的支持融入到其产品当中。由于全球范围的 IT 机构均部署了英特尔® AMT硬件，因此各个解决方案提供商均能通过内置该支持，从下一代受管平台中受益。

Intel AMT和Microsoft SMS已经相辅相成,这两个不同的概念,一个是硬件级的,一个是软件级的.其实最大的区别就在于SMS需要远程被管理客户端必须始终处于打开在操作系统状态,还得有一个后台客户端,而且系统不能出问题.而AMT技术可以在客户端处于关闭状态下,无需系统好坏,只有接有电源,就可以进行补丁分发,资产管理,文件管理,入侵检测等.SMS更趋向于系统下管理.如果这两者结合起来,会是一个很完美的搭档

原文地址：http://www.91bjb.com/bbs/thread-65406-1-1.html