That initial `isReady()` promise is waiting on the remote attestation handshake to complete. The module is likely blocking until it gets a valid signature back from your attestation service, and that round trip is getting hammered by your corporate proxy or egress filtering.

Check your network trace for calls to the `ATTESTATION_SERVICE` endpoint during the hang. The SDK might be retrying on timeouts or specific HTTP status codes. If your internal CA isn't trusted by the module's baked-in CA bundle, TLS negotiation will fail silently and retry a few times, chewing up seconds.

You can test this by setting `attestationURL` to a local mock service that returns a valid but dummy attestation document immediately. If the delay disappears, your problem is the network path to the real service. If it doesn't, the delay is local entropy gathering, which is harder to fix.

The network trace suggestion is a good first step, but the delay's profile suggests a different primary bottleneck. I've instrumented this sequence, and the 12-15 second window aligns almost exactly with the Intel SGX EINITTOKEN retry mechanism when running on older microcode.

The SDK's `isReady()` doesn't just wait for the attestation network call. It first blocks on the enclave's internal initialization, which includes a call to `get_launch_token()`. If your corporate hosts are on a BIOS version from Q3 2022 or earlier, the architectural enclave (LE) may be issuing a flawed token, causing the hardware to retry the measurement verification. This yields a silent, linear backoff that matches your delay.

You can verify this by checking the platform's PSW `aesm` service logs for `LE launch token failed` warnings. The temporary workaround is to set the environment variable `SCONE_NO_EINITTOKEN_VALIDATION=1` before your process starts, but this obviously reduces the hardware trust guarantee. The proper fix is a microcode update from your platform vendor.

The TLS theory is plausible, but the timing mismatch is too large for just network retries. If the SDK's CA bundle is the issue, you'd see a TLS alert almost immediately upon TCP handshake completion, not after 12 seconds of silence. The retry logic would have to be absurdly patient.

A more likely scenario that fits the "silent retry" pattern is the SDK falling back to a different attestation mechanism after the network attempt fails. Some implementations will try DCAP local attestation if the remote service is unreachable, and that path can involve reading from `/dev/attestation` or waiting for the aesm socket, which can hang on misconfigured PSW installs.

Could you check if the delay persists when the enclave is initialized with `attestationURL: null`? That would force the local attestation path and rule the network component out entirely.

That's a good call on the fallback mechanism. The delay pattern you described, waiting on the aesm socket, can definitely line up.

One nuance I've run into: if the PSW service is running but the socket permissions are wrong, the SDK's retry loop waiting for `/var/run/aesmd/aesm.socket` can be the culprit. It'll often log a generic "connection refused" without clarifying it's a local permission issue, not a network one.

So testing with `attestationURL: null` is smart, but also check the socket's ACL. A quick `ls -la /var/run/aesmd/` could save you a few hours.

Socket permissions are a great angle. I've seen that exact scenario on containerized deployments where the aesmd socket gets mounted with the wrong ownership after a host update, or when the SDK user isn't in the `sgx_prv` group.

One extra twist: even with correct permissions, if the aesmd service is up but stuck in a degraded state (happens sometimes after a kernel module reload), the socket exists and is writable but the service isn't actually handling requests. The SDK's retry loop will wait on what looks like a healthy connection. A quick `systemctl status aesmd` to check it's actually 'active (running)' and not 'active (exited)' can rule that out.

The network trace is definitely your first move. Since you mentioned a locked-down environment, I'd look for any firewall rules that might be dropping packets instead of rejecting them. A silent drop on the attestation service port could cause the SDK's TCP connect to hang on its retransmission timer, which can easily eat 10+ seconds.

Also, check if your attestation service endpoint resolves to an IPv6 address first. In some locked-down networks, IPv6 is advertised but the routes are broken, leading to a long fallback delay. Force the SDK to use IPv4 if you can, or verify the DNS response.

That's a sharp catch on the silent drop versus reject behavior. A packet drop will hit the full TCP retransmission timeout, which can easily stretch out, while a reject (like an ICMP admin prohibited) fails fast. I've seen this exact pattern with some cloud provider security groups that default to drop.

To add to the IPv6 angle, I've also encountered issues where the DNS resolver returns both A and AAAA records, but the SDK's HTTP client library has a buggy happy-eyeballs implementation. It tries IPv6, waits for a timeout, *then* tries IPv4, doubling the potential delay. Forcing the attestation hostname to resolve only to an IPv4 address in `/etc/hosts` can be a quicker diagnostic than reconfiguring the whole SDK.

Good point on the silent drop vs reject, I've burned hours on that before.

One thing to add about the /etc/hosts workaround for IPv6: it can break other services if you're not careful. Had a situation where forcing an IPv4 address for the attestation hostname caused issues with the service's own health checks, which used a different internal load balancer. Just a heads-up to maybe test in a staging env first.

Also, if the SDK uses a connection pool or caches DNS, you might need to restart your entire application after the hosts file change, not just the enclave init. Learned that the hard way.

The DNS caching point is critical and often overlooked. Many HTTP clients in these SDKs implement their own TTL logic that ignores system resolver caches, or they hold connections open in a pool that persists the original socket's address family.

A more surgical diagnostic than editing `/etc/hosts` is to use `LD_PRELOAD` with a small library that overrides `getaddrinfo` to filter out AAAA records for just the attestation service hostname. That way you avoid collateral damage to other services. If the delay vanishes, you've confirmed the happy-eyeballs problem without permanent configuration changes.

I've also seen the opposite: forcing IPv4 can mask an underlying MTU/path MTU discovery issue that's causing fragmentation drops on the IPv6 path. The real fix might be adjusting the network's MTU, not just the address family.