Skip to main content

Troubleshoot SGX attestation issues

Use this guide when an operator-backed localnet flow fails around identity, registration, or attestation rather than around public API usage.

Prerequisites

  • You already know the task is node-operations work.
  • You are working on a localnet or enclave-capable runtime path.
  • You can inspect host SGX device state and the environment passed to the operator binaries.

1. Confirm the localnet attestation mode

For the standard localnet path, confirm these conditions first:
CheckExpected result
report modeREPORT_TYPE=SELF
debug posturelocal debug builds must not be treated as DCAP mode
mode classificationyou are on an enclave-capable operator path, not a trader or public API path
If localnet is trying to use a different report mode, correct that before you continue.

2. Verify SGX device access on the host

Check that the SGX devices use the documented group-readable model rather than root-only access.
DeviceExpected posture
/dev/sgx_enclavegroup-readable with the SGX access group
/dev/sgx_provisiongroup-readable with the provisioning-device group
/dev/sgx_vepcgroup-readable with the SGX access group
If device permissions drift from the documented 0660 plus group model, fix host access before you debug the application layer.

3. Verify PCCS and AESM reachability

Attestation flows depend on the platform services being reachable.
DependencyHealthy posture
PCCSreachable from the operator environment
AESMrunning before the operator-backed workflow starts
If either dependency is unavailable, treat that as the primary blocker rather than investigating later request or registration symptoms first.

4. Verify enclave build flags against the runtime flags

The runtime flags must match the built enclave artifacts. Check:
  • SGX_DEBUG matches how the enclaves were built
  • SGX_PRERELEASE matches the build and runtime expectations
  • the operator and KYC identity paths can both run with the current SGX flag combination
If identity fails under the current debug flag, rebuild the affected enclave artifacts with matching flags before continuing.

5. Verify where the failure occurs

Use the failing stage to choose the next diagnosis:
Failing stageMost likely next focus
identitySGX device access or debug-flag mismatch
acquire registration reportattestation mode, PCCS/AESM reachability, or custodian/report environment mismatch
registration-dependent startupreport parsing, registration sequencing, or operator-readiness dependency chain
Do not collapse those stages into one generic “SGX is broken” diagnosis.

6. Verify the registration-side inputs

If the issue appears after identity succeeds, recheck the registration-side assumptions:
  • the report contains the required registration claims
  • the localnet flow still uses the expected custodian and signer environment
  • registration is happening in the correct sequence before operator readiness is expected

7. Decide the next route

If the problem is…Use this next
fixed mode, URL, or readiness factsNode Operations Reference
a wider environment-readiness problemHow to Verify Operator Localnet Readiness
a private runbook or host-remediation taskSupport Channels
Last modified on April 12, 2026