Intel AMT and vPro Security Guide: Provisioning, Control Modes, TLS and Exposure Control

Intel Active Management Technology (AMT) gives administrators power control, remote console and storage redirection on vPro laptops and desktops below the operating system, so its credentials, certificates and network reach need the same care as a server baseboard management controller. Many fleets ship with vPro hardware where AMT is either left unconfigured or provisioned once by a support team and never reviewed. This guide covers how AMT is provisioned, how Client Control Mode and Admin Control Mode change what a remote operator can do, which ports and TLS settings to use, how to disable AMT where it is not needed, and how to monitor it. It is written for endpoint engineers, desktop support leads and security architects running vPro fleets. Server BMCs are covered in the Firmware and Boot Security Guide, and network design for management traffic in the Out-of-Band Management Network Design Guide.

This is an independent guide from NHI Mgmt Group, based on Intel's public documentation as of November 2026. It is not sponsored or reviewed by Intel. Product features change, so confirm settings against Intel's current documentation.

Key takeaways

• Decide per device: provision properly or disable. Since Release 12.0 AMT can be globally disabled, which turns off all out-of-band network interfaces and cannot be reversed remotely.
• Control mode sets the consent boundary. In Client Control Mode, user consent with a 6-digit on-screen code is required for KVM, Serial over LAN and storage redirection and cannot be turned off.
• Use TLS ports only. Use 16993, 16995 and 664; recent platforms with CSME 16.1 and later no longer accept remote connections on the non-TLS ports 16992, 16994 and 623.
• AMT credentials are privileged non-human secrets. The AMT admin password, MEBx password and provisioning certificate give hardware level control of every enrolled machine, so vault and rotate them.
• Remote reach must be designed. Client Initiated Remote Access (CIRA) tunnels to a management server from outside the enterprise, so the server, its certificates and its admin accounts become part of the attack surface.

What AMT and vPro are

vPro is Intel's business platform brand; AMT is the manageability firmware feature that runs on the Converged Security and Management Engine (CSME), independently of the host operating system. Once configured, AMT listens on the network interface and accepts WS-Management commands for power control, hardware inventory, boot control and redirection, including when the operating system is not running. That is the value for support teams and the reason it must be governed.

Provisioning and control modes

AMT has two configuration types: Host-based Configuration, pushed by software running in the operating system, and Remote Configuration, which uses a provisioning server and a provisioning certificate. The result is one of two control modes.

• Consent code: the 6-digit code is drawn by the Intel GPU as a sprite that the host operating system cannot read, and the user reads it to the technician. This makes consent resistant to malware on the host.
• Choosing ACM: ACM removes the consent requirement only if you set it to None. For most office fleets, keep consent at KVM only or All even in ACM, and reserve None for unattended systems where no user is present.
• Moving between modes: Intel's support article describes moving from CCM to ACM with ACUConfig MoveToACM where a remote configuration server exists, or unconfiguring and reconfiguring through MEBx or USB key. Some OEM BIOS menus include an "Allow USB Key provisioning" setting that must be enabled for USB configuration.
• PKI DNS suffix persistence: Intel notes the PKI DNS suffix set in MEBx persists through a full unprovision. Check it when repurposing devices.

For the certificate side, follow the Enterprise PKI Design and CA Hierarchy Guide.

Passwords, certificates and where identity fits

AMT introduces several credentials that are not tied to a person, and each one grants hardware level control. Treat them as privileged non-human identities. Intel's documentation lists the CSME (physical access) password, the AMT Admin Digest User password, the Digest Master Password, Active Directory user accounts and, on older releases, an RFB password for port 5900.

• MEBx password: used only at boot for local access to MEBx. Intel's support article notes the factory password on most devices is "admin"; set a unique value per device or per batch and store it in a vault. It initially matches the Master Digest Password but is stored separately.
• AMT admin password: set by the provisioning profile. Generate it per device where your management tool supports it, rotate it on staff changes and never reuse it across fleets. See LAPS vs PAM Vaulting for the same per-device pattern applied to local admin accounts.
• Active Directory integration: Intel lists Active Directory integration as a configuration option, so named administrator accounts can be used instead of sharing the digest admin account. Use it where supported so actions are attributable.
• Provisioning certificate: its private key lets the holder put any vPro device in your domain suffix into ACM. Hold it on the provisioning server only, protect it like a code signing key and track its expiry.
• CIRA credentials: the device authenticates to the MPS with a client certificate (mutual TLS) or a username and password, and validates the MPS certificate against its CN or FQDN with a trusted root. Prefer mutual TLS.

Console accounts on the management server (for example Intel Endpoint Management Assistant, EMA) hold the keys to every device. Put them behind phishing-resistant MFA and your Privileged Access Management Guide controls.

Network ports and TLS

• Platform direction: Intel's reference guide states that on Alder Lake platforms with Raptor Lake CPUs and CSME 16.1, remote connections to 16992, 16994 and 623 are no longer supported, and on Arrow Lake with CSME 19 non-TLS connections are not supported at all, including locally.
• Certificates after firmware update: Intel's Alder Lake guidance explains that a firmware update on a non-TLS system disables the non-TLS ports and generates a new self-signed certificate; replace it with a certificate from a trusted CA for production and use the AMT-Authenticate API so consoles verify they are talking to a genuine AMT device.
• Older fleets: on earlier platforms that still offer non-TLS ports, configure TLS in the provisioning profile and filter 16992, 16994 and 623 at switches and firewalls. See the Out-of-Band Management Network Design Guide.

Remote reach: CIRA and environment detection

CIRA lets a device that is off the corporate network open an outbound TLS tunnel to an MPS. The device decides whether it is inside the enterprise using environment detection: a list of domain suffixes configured by the setup application. Inside, it does not open the tunnel and listens locally instead.

• Use a hard to guess intranet suffix where you force tunnels: Intel's EMA troubleshooting article notes that administrators can set a fictitious intranet suffix to make CIRA tunnels always open, and that it should be hard to guess so someone cannot use it to stop CIRA and open the local management ports.
• Treat the MPS as internet-facing privileged infrastructure: patch it, restrict its admin interfaces, log every session and keep it in a separate management zone.
• Validate server identity: configure the MPS by FQDN with a certificate chained to a root the device trusts; if an IP address is used, a CN must also be set.

Disabling AMT where it is not needed

If a device class has no out-of-band use case, disabling AMT reduces the managed surface. Intel's reference guide states that from Release 12.0 AMT can be globally disabled, which turns off all out-of-band network interfaces, closes the local interface to the Local Manageability Service, prevents the BIOS Manageability Feature State from being enabled and prevents provisioning.

1. From MEBx: confirm Manageability Feature State is disabled, then set Intel AMT to Disabled.
2. From software: management tools can call the CFG_DisableAndClearAMT MEI command.
3. Re-enabling: AMT cannot be re-enabled remotely; it must be enabled locally through MEBx, after a reboot if it was disabled there. Plan this before disabling devices you may later want to manage remotely.
4. OEM controls: many OEMs expose an Intel ME or AMT state setting in BIOS or their configuration tools. Manage it with your BIOS settings baseline; see the BIOS and UEFI Settings Management Guide.

Decision guidance: provision in ACM with TLS, AD authentication and consent where you have a support or recovery use case and a team to own the console. Disable where AMT is unused, especially on devices for high-risk users who travel. A small organisation without a management server usually gains more from disabling than from a partly configured CCM deployment; a large fleet with remote staff often benefits from ACM with CIRA, provided the MPS and certificates are run as tier 0 assets.

How to implement

1. Inventory (weeks 1 to 2): list vPro-capable devices, AMT state (unconfigured, CCM, ACM, disabled), firmware version and who provisioned them. Your management console and OEM tools report provisioning state.
2. Decide per device class (week 3): provision, leave unconfigured with MEBx password set, or disable.
3. Build the platform (weeks 3 to 6): management server in a management zone, provisioning certificate from your PKI, TLS-only profile, AD integration, consent policy, per-device admin passwords in a vault.
4. Pilot (weeks 6 to 8): a pilot ring of IT devices; test KVM, redirection, CIRA from home networks and consent prompts. Confirm non-TLS ports are closed with an authorised internal scan.
5. Roll out in rings (weeks 8 onward): by site or department, with firewall rules applied before devices join.
6. Rollback: unconfigure through the management tool or ACUConfig unconfigure, which returns devices to an unprovisioned state; re-provision with a corrected profile.
7. Keep firmware current: apply CSME and BIOS updates through your firmware process and follow Intel's Product Security Center advisories. See the Firmware and BIOS Update Management Guide.

Detection and measurement

• Network: alert on connections to 16992 to 16995, 623 and 664 from anything other than management subnets; a user workstation talking to another workstation's AMT ports is unusual.
• Console audit: log every KVM, redirection and power action with operator identity, device and time, and forward to the SIEM.
• Endpoint posture: flag devices whose AMT state differs from the baseline, for example CCM where ACM or disabled is expected.
• Boot anomalies: storage redirection boots show as unexpected boot sources; correlate with console session logs.

Metrics: percentage of vPro devices in an approved state (target 100%); percentage of provisioned devices using TLS-only ports; percentage with unique, vaulted admin passwords; redirection sessions without a linked ticket; days to apply CSME firmware updates; age of the provisioning certificate relative to expiry.

Framework mapping

Common failure patterns

• Provisioned once, never owned: a pilot left devices in CCM or ACM with one shared admin password and no console owner.
• Same password everywhere: one AMT admin password across the fleet turns a single leak into fleet-wide hardware control.
• Consent set to None by default: following a convenience article for help desk speed on attended office devices removes the user's visibility of remote sessions.
• Flat network reach: AMT ports reachable from every user segment instead of only from management subnets.
• Provisioning certificate on many machines: the private key copied to technician laptops instead of held on the provisioning server.
• Repurposed devices keep settings: PKI DNS suffix and MEBx passwords carried over when devices move between business units.

Practitioner checklist

• Record AMT state for every vPro device and set an approved state per device class.
• Disable AMT through MEBx or management tooling where there is no use case.
• Use ACM with TLS-only ports 16993, 16995 and 664 for provisioned fleets.
• Keep user consent at KVM only or All for attended devices.
• Set unique MEBx and AMT admin passwords per device and store them in a vault.
• Use Active Directory integration so AMT actions are tied to named administrators.
• Hold the provisioning certificate only on the provisioning server and track its expiry.
• Restrict AMT ports to management subnets and alert on other sources.
• Run the management server and MPS as privileged infrastructure with MFA and session logging.
• Apply CSME and BIOS firmware updates promptly through your firmware process.

Standards and references

• Intel: Intel AMT Basic Concepts
• Intel: User Consent
• Intel: AMT Implementation and Reference Guide, Manageability Ports
• Intel: AMT Implementation and Reference Guide, Disabling Intel AMT
• Intel: Alder Lake Non-TLS Update Support Guidance
• Intel Device Management Toolkit: Control Modes
• Intel: AMT Implementation and Reference Guide, Client Initiated Remote Access
• Intel: Product Security Center

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Out-of-Band Management Network Design Guide · BIOS and UEFI Settings Management Guide · Endpoint Hardening Checklist