A. One layer among many
ACSE-PME is a hardening layer aimed at one phase of an attack: the reconnaissance an outside attacker performs before acting — scanning, fingerprinting and mapping a target so they can stage an exploit. By continuously rotating the observable protocol and cryptographic identity of a protected host, and verifying each change from outside, it shortens how long that map stays accurate.
It is designed to sit alongside the controls that address other phases and other weaknesses: patching and secure development, MFA / identity and access management, endpoint detection and response (EDR), web application firewalls (WAF), network segmentation, and backups. ACSE-PME does not replace any of them, and deploying it does not reduce the need for them.
B. What it counters, and what it does not
| Threat | Effect of ACSE-PME | Controls that address it |
|---|---|---|
| External scanning & fingerprinting of rotated surfaces | Reduces the lifetime and value of the observation — a fingerprint of the TCP/IP stack, TLS presentation, certificate, listening port, address or DNS name is accurate only until the next cycle. | This is ACSE-PME's role. |
| Exploits whose success depends on a rotated property | Harder to aim: an exploit staged against an observed surface state may target a state that has changed. | ACSE-PME, alongside patching. |
| The underlying vulnerability (unpatched framework, SQL injection, weak login) | Not fixed. Rotation hides the wrapper, not the weakness — the vulnerability is still exploitable wherever it is reachable, on whatever surface it moves to. | Patching, secure development, input validation, WAF. |
| Stolen or phished user credentials; VPN / remote-access abuse | Not addressed today. ACSE-PME can rotate certain service and machine account credentials (built, see §E), but it does not rotate human user logins and does not stop an attacker who signs in with valid credentials. | MFA / IAM, conditional access, phishing-resistant authentication. |
| Insiders; attackers with persistence or an active session | Largely unaffected. An attacker already inside, or holding a live session, operates from within and does not need to re-scan. The "map expires" property is about external reconnaissance. | EDR, least privilege, segmentation, session management. |
| Supply-chain compromise (trusted software updates) | Not addressed. Code arriving through a trusted update path bypasses surface rotation entirely. | Software signing, SBOM, build integrity, vendor assurance. |
| Ransomware after initial access | Limited. It makes some lateral reconnaissance noisier and shorter-lived; it does not stop encryption once an attacker has access. | EDR, immutable backups, segmentation, least privilege. |
| Customer devices, and the customer↔service path | Out of scope. ACSE-PME protects the surfaces of systems it runs on, not the client or the network path to it. | Client endpoint security, TLS, zero-trust access. |
C. How legitimate users and systems keep working
If the surface changes, every real client, load balancer, firewall rule and monitoring tool must learn the new configuration. That happens through a discovery channel, and it is important to be clear about it:
- Certificates: clients trust the organisation's certificate authority and pin the CA, not the leaf certificate — so a rotated leaf is still trusted, while leaf pinning would break (see the operational FAQ).
- Addresses and ports: resolved through DNS with authenticated updates, or through service discovery, so legitimate clients find the current address.
- Rollout: opt-in per surface and per ring (lab → non-production → production), so a surface is only rotated where its discovery path is in place.
The discovery channel is itself a target. Whatever tells legitimate clients the current configuration is a thing an attacker may try to read or abuse, and anyone with legitimate access — a phished employee, a stolen VPN credential, malware on an authorised machine — receives the current map automatically. We say this plainly: ACSE-PME raises the cost of external reconnaissance; it does not hide the configuration from parties with legitimate access. Protecting the discovery channel (authenticated DNS updates, CA trust, access control on the Control Plane) is part of deploying it.
D. The Control Plane is the most sensitive component
One system coordinates the estate, decides verdicts, and holds keys and the audit chain — so it is the highest-value target in the design. What it holds and how it is protected today:
- Node keys are generated on the nodes and are never seen by the Control Plane.
- Agent↔Control-Plane traffic is mutual-TLS; stored secrets are envelope-encrypted; the audit chain is signed and hash-linked.
What is open, stated plainly:
- ASMP frames are authenticated, not encrypted. Group secrets rotate on a schedule, and a retired secret is deleted and no longer accepted. Deletion is not cryptographic erasure: copies can remain in database logs and in backups taken before the rotation. The group secret is delivered sealed to each node's long-term key, so a recorded delivery could be opened if that key were later compromised. This is not forward secrecy.
- The Control Plane currently also acts as the certificate authority and the leap relay — concentrating trust that future work aims to reduce.
- High-availability of the Control Plane, and external anchoring of the audit chain (so a compromised Control Plane cannot silently rewrite history), are not yet built.
E. Evidence and assurance — what we have, and what is pending
Engineering-quality evidence (not security evidence): the automated test suite (2,130 tests passing, 0 failed, as of 20 October 2026) demonstrates that the software does what it is specified to do. A passing test suite is a measure of code quality, not of security.
Formal analysis: ProVerif models of three ASMP/1.0 message types establish, for the modelled protocol under a Dolev-Yao adversary, handshake secrecy and mutual authentication, leap origin authentication (relay checks a per-node envelope), and node-granted protected actions. Not covered by these three message-type models: single-acceptance (shown by tests) and zero knowledge (none claimed). ASMP frames are authenticated, not encrypted. Group secrets rotate on a schedule, and a retired secret is deleted and no longer accepted. Deletion is not cryptographic erasure: copies can remain in database logs and in backups taken before the rotation. The group secret is delivered sealed to each node's long-term key, so a recorded delivery could be opened if that key were later compromised. This is not forward secrecy. See WP-07.
Security-relevant measurements we have made:
- External verification: a verifier observes each protected host and the Control Plane decides the verdict from signed observations, so a node that misreports its own state is detected.
- State distinguishability: observed surface states are distinguishable by standard tools (nmap, p0f) across cycles, and a fingerprint-linkability study measured L = 0.5230 (n = 9,000, 13 October 2026) against a target bound of ≤ 0.535 — inside the ideal-random control's range.
Which surfaces act on real systems today — in three tiers, each matching its internal claims-ledger entry:
- (i) Verified by an independent verifier observing from outside: the Linux host TCP/IP stack, the TLS front, the service address and its published DNS name.
- (ii) Built and measured on the host itself, not yet observed by an independent verifier: the Windows and macOS host stacks.
- (iii) Management plane — credential rotation of devices and BMCs (credential rotation, not surface mutation): SSH credential rotation is lab-proven against a real sshd; Redfish against a mock BMC; NETCONF, SNMPv3 and IPMI are built and awaiting live verification.
The remaining profile behaviours operate on an in-memory model pending integration. The authoritative, dated status is tracked in an internal claims ledger.
Trusted-execution status: of the TEE/TPM adapters, only TPM 2.0 is exercised on real hardware today; the others are not yet hardware-verified.
Independent penetration testing, an OWASP ZAP scan against a running build, CERT-In empanelled audit, third-party cryptographic review, and peer-reviewed publication are planned and not yet completed. There is, as yet, no independent audit or published external review.
F. Cryptography and post-quantum
The cryptography is classical, not post-quantum. ACSE-PME's signatures (ECDSA-P256) and its key agreement and secret sealing (ECDH-P256, and TLS via rustls) use classical elliptic-curve cryptography. There is no post-quantum cryptography in the product today, and no migration has shipped.
A crypto-agility mechanism — algorithm identifiers in every in-house format — and a hybrid ML-KEM-768 + ML-DSA migration are planned. Until they ship, the honest positions are: a recorded sealed secret should be treated as exposed to harvest-now-decrypt-later, and long-term audit signatures are classical-strength. We will not describe the product as quantum-resistant before it is.
G. Related reading
How ACSE-PME relates to the moving-target-defence field, and what is genuinely new: Related Work & How ACSE-PME Differs. Running it safely without breaking certificate pinning, firewall allowlists, compliance scans or IDS baselines: Operational Questions.
ACSE-PME is a hardening layer that shortens the useful life of external reconnaissance. It is one layer alongside patching, MFA, EDR and segmentation — not a replacement for them, and not a universal breach-stopper.