Intel AMT Infrastructure

Intel Active Management Technology (AMT) provides out-of-band management for supported Intel business devices. Ordyn uses a AMT service client to reach device. Browser KVM and SOL sessions additionally use the independently managed Relay service.

AMT management applies only to existing Ordyn endpoints.

Firmware compatibility

Intel AMT support is best effort. Ordyn has been tested with AMT 11.x and 16.x firmware only. Other firmware versions have not been validated and may behave differently.

Components

Prepare these components before assigning an Intel AMT configuration profile:

• an Edge service that the Windows agent and AMT client can reach
• an AMT service client at each managed site
• an Relay service client for KVM and SOL
• an activation credential for devices that must enter ACM or transition from CCM to ACM
• a Intel AMT operational certificate authority
• supported Windows devices with the OEM Intel MEI driver and LMS service

The AMT client must be able to reach each assigned AMT device at the IPv4 address stored on its Intel AMT endpoint interface. It rejects unsafe addresses such as loopback, link-local, multicast, reserved, and IPv6 addresses. The AMT FQDN identifies the firmware TLS certificate; the client connects directly to the AMT interface address.

Network Requirements

Source	Destination	Port and protocol	Purpose
Windows agent	Assigned Edge	WSS TCP 443	Control and provisioning
Windows agent	Local Intel LMS	HTTP TCP 16992	AMT 11–13 compatibility provisioning on the same Windows device
AMT client	Assigned Edge	WSS TCP 443	Enrollment, commands, and results
AMT client	AMT device	TLS TCP 16993	Firmware management
AMT client	AMT device	TLS TCP 16995	KVM, SOL, and redirected media
AMT client	Cache node	HTTPS TCP 443	Authorized media download
AMT client	Relay service	WSS TCP 443	KVM and SOL session data
Browser	Relay service	WSS TCP 443	KVM and SOL console data
Relay service	Assigned Edge	WSS TCP 443	Enrollment and control
Runner	tsci.intel.com	HTTPS TCP 443	ODCA trust and revocation refresh
Net node	Local network	TCP 16992 and 16993	Intel AMT address discovery during enabled IPAM scans

Only the relay requires public inbound access. The AMT client, Windows agent, and AMT devices require no public inbound route. Managed firmware traffic uses TLS ports 16993 and 16995.

AMT 11–13 provisioning can temporarily use port 16992 through Intel LMS on the Windows device. Ordyn permits this only on localhost, only for an explicitly authorized provisioning or recovery operation. The operation installs and verifies the managed firmware TLS identity before normal AMT-client management begins on port 16993. Port 16992 can also be probed as unauthenticated discovery evidence. Remote plaintext management and port 16994 are unsupported.

During provisioning, the Windows agent and AMT client use their Edge connections. They do not require direct network connectivity to one another.

Redirected media is prepared from an Ordyn ISO or IMG file through the assigned cache node. The AMT client verifies the complete image before presenting it read-only to firmware. Firmware selects the compatible storage-redirection method automatically. A successful mount confirms that firmware accepted the image. A media mount can remain active independently of the KVM console and is released by the operator, its configured automatic-unmount time, or an interruption of the assigned AMT service client.

For automatic recovery from a changed AMT IPv4 address, configure the device network in IPAM with common protocol probes, automatic scans, and a selected net node on the same layer-2 network. A matching MAC and open AMT port identify only a candidate. The AMT client must validate the tenant AMT certificate authority, expected AMT FQDN, administrator credential, and platform UUID before Ordyn replaces the stored interface address.

If address discovery does not update an endpoint, confirm that the IPAM scan completed successfully, common protocol probes are enabled, the selected net node can observe the device MAC directly, and the AMT client is connected. Review the endpoint's AMT operation history for certificate, FQDN, credential, or platform identity validation failures.

Installation

Prerequisites:

• Docker installation
• Cosign installation
• network access from the AMT host to the assigned Edge service and managed AMT devices

Open Services > Intel AMT, select Add AMT client, and configure its name, tenant, assigned Edge service, runtime log level, and enabled state. Copy the created service client ID.

Checkout the AMT deployment folder from the Ordyn compose repository:

if [ ! -d /opt/ordyn-compose/.git ]; then
  git clone --filter=blob:none --sparse https://github.com/ordyn-project/compose.git /opt/ordyn-compose
fi
cd /opt/ordyn-compose
git sparse-checkout add amt

Create the environment file:

cd /opt/ordyn-compose/amt
cp .env.example .env

Set these values in .env:

ORDYN_AMT_EDGE_HOST=ordyn-edge.example.com
ORDYN_AMT_SERVICE_CLIENT_ID=<service-client-id>

Pull and verify the service image:

docker compose pull
python3 /opt/cosign-docker-verify/verify.py

Continue only when the AMT image verifies successfully and no failed verification message appears. Open Administration > Enrollment Tokens, choose Service client and Intel AMT, and select the same tenant, Edge service, and AMT service client. Copy the one-time token, stop any running AMT container, and enroll the persistent service state:

docker compose stop amt
printf '%s' '<enrollment-token>' | docker compose run --rm -T --no-deps amt npm run enroll -- --token-stdin

After enrollment succeeds, start the service:

docker compose up -d amt

To renew, recover, or replace the AMT service-client certificate, issue a new token and run forced enrollment while the service is stopped:

docker compose stop amt
printf '%s' '<enrollment-token>' | docker compose run --rm -T --no-deps amt npm run enroll -- --token-stdin --force

Run docker compose up -d amt only after forced enrollment succeeds.

AMT service clients

Connected clients perform availability checks for their managed devices. The default interval is five minutes. These checks read the firmware power state over TLS and keep endpoint reachability and supported power actions current even when Windows is offline.

Each tenant has one active AMT client. Create separate tenants for sites that require independent client routing. Assigned Intel AMT configuration profiles automatically use the tenant's active client.

Activation Credentials

Activation credentials belong to an AMT client and are generated by Ordyn. When a device must enter ACM or transition from CCM to ACM, Ordyn selects an active, valid, unexpired credential whose root fingerprint is reported as trusted by the firmware and whose DNS suffix matches the planned AMT name. ECC credentials are preferred when more than one compatible matching root is trusted. Ordyn's AMT 11–13 compatibility workflow requires the RSA-2048/SHA-256 activation profile.

An ACM activation attempt uses one selected activation credential. If an AMT 11–13 device that must enter ACM has no eligible RSA-2048/SHA-256 credential with matching firmware trust and DNS suffix, provisioning stops without changing the firmware. Create the credential, generate and apply its setup.bin, and run preflight again before retrying provisioning.

Adopting a supported device that is already in the control mode selected by its configuration profile does not use an activation credential or require an Ordyn activation root. This applies to existing CCM and existing ACM devices. Configure the endpoint's current Intel AMT administrator password before adoption. Ordyn preserves the existing ACM provisioning-trust hashes, replaces the contents of the device's WS-Man certificate store, and installs an operational device certificate for managed TLS connections.

Select a certificate profile when creating the credential:

• ECC P-384 / SHA-384 is the default and recommended profile.
• RSA-2048 / SHA-256 compatibility is available for older firmware that cannot use ECC activation certificates.

Use an activation credential when you control device setup and can seed its Ordyn-generated activation root in firmware.

The credential is client-scoped and contains one DNS suffix. The suffix is fixed because it is part of the generated certificate Create another activation credential when a different suffix is required Every setup.bin generated from a credential uses its suffix. Use Intel AMT Setup to download and apply the artifact before provisioning:

• a reusable trust-only artifact contains the activation root and no device administrator password
• a per-device recovery artifact contains a unique MEBx recovery password, expires after 24 hours, and can be downloaded once

Treat every downloaded setup artifact as sensitive.

Ordyn maintains one activation authority for each tenant and activation profile. The self-signed activation authority is the firmware setup trust anchor; it is separate from the tenant's operational authority used for managed TLS connections. Activation authorities are valid for 15 years, and each activation credential receives a provisioning certificate valid for five years. Creating another credential for the same tenant and profile reuses the active activation authority and issues a new certificate. The authority and every issued provisioning certificate are visible under Administration > Certificate Authorities.

Importing externally issued provisioning certificate chains or private keys is not supported. Activation through an existing Trusted Endpoint Provisioning (TEP) owner identity is also not supported.

Intel ODCA Trust

Intel On-Die Certificate Authority (ODCA) data establishes trust in supported firmware identities.

Use a Windows or Linux Runner to download the bundle:

1. Open Operations > Infrastructure Jobs and create an infrastructure job.
2. Select a Runner pool whose Runner can reach tsci.intel.com on TCP 443.
3. Add a Refresh Intel ODCA trust step.
4. Run the job.
5. Review the task result and the Intel ODCA tab under Administration > Services > Intel AMT.

For an installation without a Runner, obtain the same reviewed artifacts through an approved external process and use Import bundle on the Intel ODCA tab. Offline imports receive the same cryptographic validation and audit treatment.

Secure host-based activation requires both an exact match to the firmware certificate fingerprint reported locally by Intel PTHI and a valid Intel ODCA chain with current revocation data. Missing, invalid, expired, or revoked trust data blocks the operation.

Provisioning fails when required trust data is missing, invalid, expired, or reports revoked firmware. Firmware advisory matches that do not represent a hard trust, TLS, protocol, or revocation failure appear as warnings.

Intel AMT operational certificate authority

Each AMT-enabled tenant uses an Ordyn-managed operational certificate authority. Create and inspect it under Administration > Certificate Authorities by selecting the Intel AMT operational purpose and the tenant.

The authority signs:

• AMT device server certificates

Ordyn uses an RSA-2048 authority with SHA-256 as its operational compatibility policy across supported Intel AMT generations. AMT device server keys are generated by firmware. Ordyn selects the server-key profile from the firmware capabilities collected during preflight. AMT 11–14 and AMT 15 versions before 15.0.30.1545 use an RSA-2048 server key with a SHA-256-signed certificate request. AMT 15 beginning with 15.0.30.1545 and supported newer firmware prefer ECDSA P-384 with a SHA-384-signed certificate request and retain RSA-2048 as a fallback. Ordyn signs the issued device certificate with SHA-384, so an RSA-2048 device certificate can correctly show SHA-384 with RSA Encryption as its certificate signature algorithm. The operational authority profile remains the same for every supported generation.

Operational authorities are valid for 15 years and enter overlap rotation six years before expiry. Device certificates are valid for five years and enter renewal one year before expiry. Replacement certificates are installed and verified before retired Ordyn certificates are removed. Certificate installation progress is preserved for recovery. After an interruption, an authorized Resume reuses the exact generated key, request, certificate, and installed references recorded for the operation. Provisioning, renewal, reconciliation, and their recovery paths remove only material identified as Ordyn-managed and do not delete an external key or certificate to free a slot.

Adoption has a different certificate-store policy. It removes every existing mutable server certificate, trusted root, client certificate, and key pair from the device's WS-Man certificate store, regardless of which management system created it. When the current server certificate is required to keep the adoption connection authenticated, Ordyn retains that exact certificate and matching key until the new Ordyn identity has been installed and verified, then removes them. The final store contains only the verified Ordyn server certificate, its installed chain, and its matching firmware key. ACM provisioning-trust hashes, AMT users, and ACL entries are outside this store and remain installed. Firmware features that depended on a removed client certificate, including certificate-based 802.1X or CIRA configurations, require separate reconfiguration after adoption.

The authority detail page shows the public certificate and lifecycle state. Its Certificates tab provides the paginated issuance history for AMT device certificates. Activation-authority pages use the same view and list provisioning certificates.

This issuance history is distinct from the certificate inventory reported by a specific device. Use the endpoint's Hardware > Intel AMT > Certificates page to compare firmware provisioning trust hashes and the current WS-Man certificate store, including external entries that Ordyn did not issue.

AMT connections require strict hostname and CA validation with TLS 1.2 or newer. AMT 11 devices may use the documented AES-CBC TLS 1.2 compatibility suite only when firmware advertises no permitted stronger suite; the endpoint shows a security warning. SHA-1, RSA keys smaller than 2048 bits, and elliptic curves other than P-384 in AMT certificate workflows are rejected.

See Intel AMT Certificates and Renewal for every certificate purpose, fixed validity periods, automatic and forced renewal, authority rotation, and expiry recovery.

Logging, Diagnostics, and Alerts

AMT clients provide health and diagnostics through the support-bundle workflow. Local structured logs are retained for 14 days within a bounded disk allowance. Relay diagnostics are documented under Relay.

Provisioning and adoption diagnostics record milestone and failure context for the operation, selected route, operational certificate request, certificate installation, connection lifecycle, and final verification. Endpoint support bundles correlate these records with the endpoint agent's safe LMS and TLS diagnostics. Credentials, certificate private material, WS-Man bodies, and provisioning bytes are excluded.

An administrator can enable redacted WS-Man XML debugging for up to 15 minutes. The page displays a warning and the expiry time. Debugging never records credentials or other sensitive data.

Operational alerts cover:

• provisioning and recovery failure
• repeated or sustained drift
• AMT authentication failure
• device or AMT-client outage
• certificate, CA, or activation-credential expiry and renewal failure
• missing or stale Intel revocation data
• capacity exhaustion and repeated protocol abuse
• redirected-media cleanup failure
• unconfirmed session termination during deletion

Alerts are raised on state transitions and deduplicated.

Service Retirement

Ordyn blocks deletion or revocation of an AMT client or activation credential while another resource references it. Move affected configuration assignments through the relevant retirement workflow first.

See Intel AMT Endpoint Management for configuration profiles, provisioning, endpoint actions, and consoles, and Relay for public KVM and SOL session transport.