Remote Configuration for Intel® AMT

With the release of Intel® Active Management Technology 3.0, network administrators no longer have to physically visit business PCs to initiate the participation of those machines on the management network. This "Remote configuration" capability involves an encryption key being entered into BIOS during device manufacture, which is subsequently used to establish connection between the management infrastructure and the PC. By setting up Intel AMT devices in this way, businesses can save substantially on deployment costs.


Intel® Active Management Technology (Intel® AMT), a component of Intel® vPro™ processor technology, offers significant efficiencies to business customers by providing hardware-based network management that allows out-of-band access to client computers. Thus, administrators can use a console application, via a management server, to connect with a firmware-resident management engine in desktop or laptop machines that incorporate Intel vPro processor technology.

That connection enables an array of remote-management capabilities, including powering the client machine up or down, as well as deploying patches or other software, gathering hardware and software asset information, or isolating malware-infected machines from the rest of the network. The key significance to this capability is that it can be accomplished even when the client machine is powered down or has a non-functioning operating system.

In order to initially set up and configure this capability, the server and client must establish a secure session to establish the credentials and network parameters that enable those platforms to be administered remotely. Previously, entering the credentials into client computers required an administrator to physically visit each machine. Because of the potential cost associated with this limitation, Intel has developed a "Remote configuration" method that allows fully remote provisioning.

In this model, client computers can be set up for management using Intel AMT without requiring a geographically present administrator. This capability can save significantly on support costs, particularly for remote sites without on-site IT personnel. This paper introduces the capabilities and limitations of Remote configuration, as well as the technical architecture and mechanisms that underlie it. The intended audience includes IT personnel who configure and provision client machines for end users, decision makers who determine what technologies are used for such operations, and security personnel who have a responsible interest in evaluating Remote configuration.

Remote Configuration in the Larger Setup Context

Intel AMT devices have two modes of operation: Small/Medium Business (SMB) Mode and Enterprise Mode. The mode is set by the manufacturer before the machine is shipped; it can be changed by an administrator during the setup process. The set-up and configuration process in SMB Mode is primarily manual, requiring an administrator to physically visit a machine, enable the AMT device, and enter configuration data using a series of BIOS screens.

Smal l Business Mode has the advantage of requiring less complex network architecture; for example, it does not require the use of Transport Level Security (TLS), which Enterprise Mode does require. On the other hand, it requires a more hands-on method of provisioning machines. For more information about setting up Intel AMT devices in SMB mode, see "Intel® Active Management Technology Small Business Configuration User Guide." As discussed later in this paper, small businesses may wish to consider managed service providers that provide Intel AMT provisioning services using Enterprise Mode.

In Enterprise Mode, Intel® Setup and Configuration Service (Intel® SCS), a free toolkit available from Intel, enables administrators to set up and configure multiple Intel AMT devices simultaneously, mapping between the device's unique user ID and the fully qualified domain name of the device. Setup and configuration using Intel SCS is secured using TLS, and it can be accomplished either manually on a client-by-client basis or using an automated script that is provided with Intel SCS. In addition to credentials being established for the client machine using Intel SCS, credential data must be populated into the BIOS of those machines, which can be accomplished by any of three means:

  • USB method uses credential data exported from Intel SCS into a file that is stored on a USB key, and the client machine is booted from the key to complete the BIOS setup. This method must be supported by the BIOS vendor.
  • Manual method requires an administrator to write down or print the credential data from the Intel SCS console, boot the client machine and enter the Intel SCS Management Engine BIOS screens, and manually enter setup information into the BIOS.
  • OEM setup method enables a hardware manufacturer to set up Intel AMT hardware before it leaves the factory, pre-populating the credentials into the BIOS and providing it in a form that can be readily imported into the IT department's Intel SCS environment. This method is required for Remote configuration.


For more information about Intel SCS, see "Intel® AMT Setup and Configuration Service: Technical Overview."

Remote Capabilities and Limitations Summary

The core capability of remote configuration is to provision Intel AMT capabilities within client machines at the end-user's location. It performs this functionality over the wired (only) production network, as opposed to using a closed or isolated subnet. Thus, Intel AMT-capable computers can be deployed over time in a non-provisioned state, and the Intel AMT functionality can be implemented on a large number of machines at once, when a sufficient base of Intel AMT-capable machines has been deployed within the organization. This capability allows gradual implementation, while not requiring initial support of management functionality for a small number of machines.

Moreover, client machines can be provisioned using remote configuration without the need for pre-deployment changes to be made by IT staff. This capability enables client computers to be sent directly from the manufacturer to the end user, without an inte rmediate stop at a corporate IT staging area. In order to support direct deployment from the manufacturer, client computers must have an encryption key populated into the Intel AMT subsystem (and provisioning must be enabled) at the point of manufacture. Once the machine arrives at the end user's location, he or she connects it to the network, powers it on, and Intel AMT configuration proceeds without further involvement from them.

Notably, in addition to the fact that the manufacturer has access to the key used in configuration, manufacturers are not required to create and maintain machine-specific configuration keys. For example, in the name of simplicity, a manufacturer could configure a large number of machines with identical keys. These security considerations are mitigated by general network security measures. That is, both the provisioning server and the AMT device must be connected to the production wired network, which helps to prevent 'rogue' servers or AMT devices from misrepresenting themselves as legitimate ones.

To help prevent an adversary from using a rogue provisioning server to illegitimately re-provision Intel AMT devices, the server uses its fully qualified domain name and a corresponding trusted root certificate to identify itself to the client. This measure provides a level of security, so long as the enterprise's DHCP infrastructure has not been compromised. Note that a public key infrastructure (PKI) is required for remote configuration. In order to prevent a rogue Intel AMT device from impersonating a legitimate workstation and potentially receiving confidential information from the provisioning server, the provisioning server may optionally authenticate Intel AMT devices using a one-time password. These and related issues are covered in more depth in the security architecture section of this document.

Client computers can also be provisioned using remote configuration from a 'bare-metal' state; that is, without a locally present operating system or OS-dependent management software agent. In that scenario, a machine can be shipped to an end user, who connects it to the network. The Intel AMT platform contacts the provisioning server using credentials that have been pre-populated by the manufacturer, and the provisioning server sets up and configures the client machine on the management network. At that point, a software image that contains an operating system and other software can be pushed down to the client PC.

The Remote Configuration Process

As alluded to above, the configuration process for remote configuration begins at the device manufacturer's location. The manufacturer makes a number of choices at this stage, based on its internal policies and preferences, a few of which are particularly relevant to the use of remote configuration.

First, the OEM must decide whether to ship the Intel AMT device set to be enabled or disabled when the host machine is in a powered-off state. This setting must be enabled to support remote configuration. Note, however, that in cases where the client machine ships with the Intel AMT device disabled but with an OS-dependent management software agent installed, remote configuration may still be possible, since the agent itself can be used to change this setting.

When an Intel AMT device is shipped in an enabled state, it is also configured in either 'listen' or 'talk' mode. In 'listen' mode, the Intel AMT device listens for provisioning-related messages on its local host interface. In 'talk' mode, in addition to listening, the Intel AMT device initiates provisioning-related messages on its network interface. Intel AMT can still be provisioned with the assistance of a hands-on, 'one-touch' approach, regardless of the initial state of either of these BIOS settings, since they can readily be changed by IT personnel in physical contact with the machine.

Figure 1. Remote configuration setup flow

Figure 1 shows a simplified process flow that represents the steps involved in remote configuration setup. The components of this architecture are as follows (for more detail, see the Intel® Active Management Technology Architecture Guide):

  • The Management Server is a third-party server application for network management that has been developed for use with Intel AMT. The Network Management Console is the administrative client interface that system administrators use to control the network management system.
  • The Setup and Configuration Service is the Intel-provided Windows* service and related components for setting up and configuring Intel AMT-enabled client computers in enterprise settings. For more information, see Intel® AMT Setup and Configuration Service: Technical Overview.
  • The Management Software Agent is a third-party client application that has been developed to work along with the Management Server (and Management Server Network Management Console).
  • The Host Embedded Controller Interface (HECI) Driver enables communication between the host OS and the Intel AMT device in the client computer. HECI is bi-directional, and either the host or Intel AMT firmware can initiate transactions. In addition, transactions can be completed asynchronously by the firmware and then synchronized later.
  • The Intel AMT Device is the firmware-based mechanism within the client computer chipset that provides out-of-band communication between the client PC and the Management Server. This device has a separate communication channel (and its own IP address) from the primary Host network interface, although they share the same physical connection. The Intel AMT device must be connected to both the network and auxiliary power in order to operate.


Note that the full sequence of the steps detailed below pertain to the case where the client machine ships with an OS-dependent management software agent installed or when such an agent is installed by an IT organization to support delayed setup. In the case of remote configuration from a 'bare-metal' state, the sequence begins with a 'HELLO' message from the client Intel AMT device to SCS and then proceeds with Step 6. The numbers in the diagram pertain to the following actions:

  1. The third-party Network Management Console application associated with the Management Server contacts the Management Software Agent installed on the client computer's operating system. The Management Software Agent, in turn, connects to the Intel AMT firmware resident on the client system and retrieves machine-specific configuratio n information, including the unique user ID (UUID) and Intel AMT versioning information.
  2. The Management Software Agent returns the UUID and Intel AMT versioning information to the Network Management Console.
  3. The Network Management Console creates a one-time password (OTP) and sends it to the Management Software Agent and SCS. The OTP is optional in most cases, although it is mandatory for delayed setup. The Management Software Agent in the client computer communicates the OTP to the Intel AMT device (through the HECI Driver) and instructs it to set that password and enable the Intel AMT network interface.
  4. Optionally, the Network Management Console communicates client-specific information such as the client's UUID, fully qualified domain name (FQDN), and Policy ID to SCS.
  5. The Management Software Agent sends a request to the Intel AMT device to open the Intel AMT network interface, and the Intel AMT device begins sending 'HELLO' messages to SCS. The network interface will stay open for six hours. Once connection is achieved between the Intel AMT device and SCS, the Management Software Agent returns a 'SUCCESS' message to the Network Management Console. The Network Management Console polls the Intel AMT device to verify that setup and configuration has succeeded within the six-hour window; if not, the Network Management Console initiates recovery actions, which are specified by the maker of the third-party network-management software.
  6. A handshake by means of Public Key Infrastructure using Certificate Hashes (PKI-CH), is accomplished between SCS and the Intel AMT device. The Network Management Console and SCS create a client certificate chain that explicitly includes the trusted root certificate from a certificate list residing in the Intel AMT Device. SCS sends the certificate to the Intel AMT Device, and the Intel AMT Device verifies the certificate against its list. For details about PKI-CH, see the discussion below.


Once the handshake is accomplished, the Intel AMT device listens to Host DHCP traffic and retrieves a DNS suffix from the DHCP server, which it verifies against the DNS suffix in the certificate. If a FQDN is configured in the Intel AMT device, the device also verifies the DNS suffix of that FQDN against the DNS suffix from the DHCP server, as well as verifying that FQDN against the Common Name (CN) in the SCS certificate.

Next, a Mutual Authentication TLS Session is initiated. The Intel AMT device sends SCS its public key, which SCS uses to encrypt a TLS Session Master Key that it creates, and then SCS sends the encrypted TLS Session Master Key back to the Intel AMT device. The Intel AMT device decrypts the TLS Session Master Key with its private key, which is then used as the shared secret for the TLS session.

If an OTP is being used (mandatory for delayed configuration, and not available for configuration from a bare-metal state), the Network Management Console and SCS ask the Intel AMT device for the OTP, which the Intel AMT device sends securely over the encrypted channel and the Network Management Console and SCS verify.

Now that an authenticated, encrypted channel has been established between the Management Server and the client machine, standard setup and configuration can commence using SCS (see Intel® AMT Setup and Configuration S ervice: Technical Overview). Then, system administrators can commence managing the PC and push software (including a full image, if desired) out to the client machine.

Additional Security Architecture Details

As discussed briefly above, PKI-CH is the handshaking protocol used between the Intel AMT device and SCS. The Intel AMT device creates a self-signed certificate to be used as a TLS server certificate, for configuration purposes only. In order to support the creation of that certification, the Intel AMT device holds a list of hashes of root certificates from accepted Certificate Authorities, as defined by Intel. The list is used to verify the configuration server certificate. Intel AMT accepts wild card domain names (e.g., * in the CN field of the configuration server configuration certificate.

The configuration server that hosts SCS must use a server certificate signed specifically for Intel AMT configuration usage, and that certificate must be signed by one of the root certificates from one of the CAs on the accepted CA list mentioned above. Finally. the configuration server must accept using self-signed certificates.

As alluded to in the process steps above, another security measure is the verification of the configuration server domain by the Intel AMT device, which compares the DNS suffix it discovers from the DHCP server against that of the CN of the configuration server. While this process serves to ensure that the configuration server is part of the correct domain, it also means that if the enterprise's DHCP infrastructure is compromised, then the Intel AMT apparatus is compromised, as well. That is, if the DHCP infrastructure were compromised, an adversary could obtain a digital certificate from a commercial CA that is on the accepted CA list and use it to defeat remote configuration security protections.

The primary mitigation to this potential vulnerability is to guard the DHCP infrastructure from attack, which does not require additional effort with respect to the implementation of Intel AMT, since network administrators must have this protection in place, in any event. Further, the Intel AMT device records the configuration server's FQDN and hash in a read-only configuration record, which assists IT in detecting rogue configuration attempts.

As an additional remediation of this risk, administrators can employ a simple 'one-touch' method: providing the configuration server's FQDN to the Intel AMT device in advance of configuration. The Intel AMT device can then use that FQDN to verify that the discovered DNS suffix matches the FQDN DNS suffix. It can also use the FQDN to verify that the DNS suffix of the CN of the configuration server certificate matches the FQDN DNS suffix.

Optionally (mandatory in the case of delayed configuration), administrators may choose to have the network management console create an OTP that allows the configuration server to authenticate the Intel AMT device. The OTP can either be set in-band (through the network interface) by the client management software agent, or else it can be set in BIOS as a one-touch measure. If used, the OTP is checked during the authentication handshake as described in the process steps above. Use of the OTP prevents the case of an adversary masquerading as a valid Intel AMT device in order to obtain Intel AMT configuration information.

The list of CHs pre-config ured in the Intel AMT device at the time of manufacture is defined by the manufacturer, and there is room for up to 20 CHs. One of those CHs can be marked for use, disallowing use of the others. Additional CHs can be configured by system administrators within the end-user organization.

Conclusion and Implementation Scenarios

The use of remote configuration to provision Intel AMT devices involves security considerations, but it enables convenient functionality in a variety of scenarios. For example, if an organization wants to deploy management functionality based on Intel AMT gradually over time, it may be beneficial to configure client machines that incorporate Intel vPro processor technology using key pairs to support remote configuration at a later date. This technique allows businesses to wait until a critical mass of machines that support Intel vPro processor technology has been deployed before rolling out the accompanying management infrastructure.

IT organizations can also drop-ship client machines directly from the vendor to a non-technical end user. Once the end user plugs the machine into the network, it will automatically handshake with the SCS configuration server and automatically get configured for Intel AMT-based network management. At that point, it can be reached on an out-of band basis, remotely powered up and down, and have the IT organization's custom desktop image pushed down to it. This method can help to obviate the need for on-site support requirements for machine setup at a remote site, which complements the general lessening of remote-site support requirements that is enabled by Intel AMT as a whole.

Remote configuration also provides possibilities for managed-service providers (MSPs) to offer enhanced remote configuration services, at reduced cost. The MSP could configure machines at a client site by means of a secure WAN connection. Moreover, as an adjunct to any of these scenarios, setup of a large number of machines can be controlled by scripts, including remote configuration and the installation of a custom client software image. The end user in that case would simply plug the new machine into AC power and a network connection, and then wait for it to be custom-configured.

Any of these scenarios, in addition to the general remote use case, provides distinct value to the deploying organization by saving on the need for hands-on contact to machines during Intel AMT setup and configuration. Enterprises now have a choice between one-touch and remote configuration, allowing them to obtain their preferred balance between security and convenience.

Additional Resources

The following materials provide a point of departure for further research on this topic:


About the Author

Matt Gillespie is an independent technical author and editor working out of the Chicago area and specializing in emerging hardware and software technologies. Before going into business for himself, Matt developed training for software developers at Intel Corporation and worked in Internet Technical Services at California Federal Bank. He spent his early years as a writer and editor in the fields of financial publishing and neuroscience.


For more complete information about compiler optimizations, see our Optimization Notice.