← Scope & Limitations Operations Security Teams · Operators · Auditors

Operational Questions: Running ACSE-PME Safely

Rotating a live system's surfaces can interact with the controls already in place. Here is how ACSE-PME affects each, what is built today, and what is planned — stated plainly.

Every answer below reflects what is built today. Anything planned is labelled planned. Where a surface is only verified on some platforms, that is stated on the scope page.

Will rotation break certificate pinning?

Pin the CA, not the leaf. ACSE-PME rotates the leaf certificate and key; a client that pins the organisation's certificate authority continues to trust the rotated leaf. A client that pins the specific leaf certificate will break — leaf pinning is incompatible with certificate rotation and must be replaced with CA pinning before that surface is enabled for it.

Firewall allowlists and ACLs?

It depends on the surface. Rotating the TCP/IP stack fingerprint or the TLS presentation does not change the address or port, so address/port allowlists are unaffected. Rotating the address or listening port does change what an allowlist must permit — so those surfaces require the allowlist to be driven from the same authenticated source (DNS / service discovery) that tells legitimate clients, or they are left static where a fixed allowlist is a hard requirement. Firewall address-object integration is part of the pilot work and is tracked openly.

Compliance and vulnerability scans?

A scanner will see a changing fingerprint across scans. Scope the scanner to the current surface via the discovery channel, or whitelist the rotation, and use the signed, hash-linked audit chain as evidence of exactly what changed and when. Note that rotation does not remove vulnerabilities — a scan will still report an unpatched service wherever it is reachable, which is the correct result.

IDS / NDR baselines — isn't unexpected change itself a warning sign?

Yes, and that is a fair concern. ACSE-PME's changes are policy-bounded and predictable to the operator: the rotation schedule and the pool of states are known to you, not arbitrary. Every transition is logged to the SIEM, so an IDS/NDR baseline can be built to expect the rotation rather than alarm on it, and analysts can tell a sanctioned rotation from a genuine anomaly by correlating against the audit stream.

Partner integrations and load balancers?

A load balancer or partner that connects to a rotated surface must learn the current configuration through the same discovery channel as any other client — CA trust for certificates, DNS / service discovery for address and port. An integration that hard-codes a leaf certificate, fingerprint, address or port must be updated to use discovery, or the relevant surface is left static for that integration. This is a design step at onboarding, per surface.

Monitoring tools?

The same rule: a monitor that targets a rotated surface resolves the current configuration through discovery, or that surface is excluded for it. Health and liveness monitoring that does not depend on the rotated property is unaffected.

What if a rotation fails — can ACSE-PME cause an outage?

Any mechanism that changes a live system carries risk, and we do not claim otherwise. ACSE-PME is built to fail safe:

  • Each change is read back to confirm it took, and validated against the expected state.
  • If the read-back or validation fails, the change is automatically rolled back to the previous known-good state.
  • A node that cannot reach a valid state enters SAFE_MODE, which restores the pre-ACSE baseline, and recovery is bounded.

This is what is built and tested. The most serious case is a rollback that itself fails, which is why the baseline restore exists as the backstop — and why rollout is staged (below) so the behaviour is proven in your environment before production.

Change control in regulated environments?

ACSE-PME's rotation is a recurring, policy-bounded change, which can be registered as a standing pre-approved change in a change-management process. We have not agreed such an arrangement with any regulator; defining it for a given regime is the operator's responsibility, and we will support the evidence (the audit chain, the policy) needed to do so.

How do we roll it out?

Opt-in per surface, in rings: lab → non-production → production. Enable one surface at a time, where its discovery path and allowlist design are in place, and widen the ring once the behaviour (including rollback and SAFE_MODE) is confirmed in your environment.

Can we turn it off instantly?

Yes. Stop the ACSE-PME service and the managed surfaces return to their pre-ACSE baseline — the privileged helper restores what it changed. This has been verified for the host stack (a clean stop, and a crash, both return the host to baseline). The host is then in exactly the state it would be in had ACSE-PME never run.

See also

Scope, Limitations & Where ACSE-PME Fits — what it counters and what it does not. Related Work — how it relates to the moving-target-defence field.