In 802.1X EAP-TLS, what does a machine-store certificate admit that a user-store one an attacker can export does not, and what does it cost to deploy?
answer
- which identity the port ends up seeing
- boot time versus logon time
- exportable key means portable credential
- no credential, no network, no enrolment
- the onboarding path is now a door
basics
~20 sA machine-store certificate authenticates the device: the port sees a computer identity, and the key can be non-exportable. A user-store certificate follows the person, so an exportable copy admits an attacker's laptop. Machine enrolment needs a management channel first.
solid answer
~50 sWhich store the certificate sits in decides which identity the authentication server sees and what a thief has to steal. A machine-store certificate is issued to the device, presented at boot before anyone logs in, and shows the server a computer identity such as `host/WS-4471.corp.example`; its private key can be generated on the device, marked non-exportable and held in a TPM, so admission tracks the hardware. A user-store certificate is issued to the person, presented after logon, and if its key is exportable it can be copied to a personal or attacker-controlled laptop that then authenticates exactly as the enrolled one did. Machine-store enrolment costs more: the device needs a management channel before it has network access, which creates a chicken-and-egg you must design around — pre-staging at build, or a restricted onboarding path that exists only to deliver the first credential.
code
text · 13 lines--- session 1, accepted (as the authentication server recorded it) ---
User-Name : host/WS-4471.corp.example
Calling-Station-Id : 3C-2A-F4-11-08-9B # client MAC
Called-Station-Id : 00-1B-0D-5F-A2-40 # authenticator MAC
NAS-Port-Id : GigabitEthernet1/0/14
EAP method : EAP-TLS
Peer certificate : CN=WS-4471.corp.example (machine store, key non-exportable)
...
--- session 2, same port, 40 seconds later, accepted ---
User-Name : [email protected]
EAP method : EAP-TLS
Peer certificate : CN=Alice Chen (user store, key exportable)
...go deeper
Know that in EAP-TLS the client proves it holds a private key, and that a certificate issued to the computer and one issued to the user are different credentials admitting different things.
Explain the mechanics: machine credentials authenticate at boot and show a computer identity; user credentials arrive at logon and, if the key is exportable, travel to any machine the user chooses.
Demonstrate that you designed for the first credential — pre-staging or a narrow onboarding path — and that you decided explicitly whether device identity, user identity, or both gate the port.
Frame enrolment authorisation as part of the admission boundary: whoever can obtain a credential can obtain network access, so the review burden and its owner move with the enrolment service, not with the switch.
## The store is not a filing detail — it is who gets admitted In EAP-TLS the client presents a certificate and proves possession of the matching private key. Where that key pair lives decides three separate things: **which identity the authentication server sees**, **when in the boot/logon sequence the port can be opened**, and **what an attacker has to obtain to reproduce the credential**. ### Machine store A machine-store (local computer) certificate belongs to the device. Its subject names the computer, so the record at the authentication server carries a computer identity. Because it is not tied to a logged-on session, the supplicant can authenticate at boot — which is what lets a device reach the network before any user is present, so management traffic, patching and remote administration work on an unattended machine. The private key is created on the device during enrolment, and on a managed platform it can be marked non-exportable and bound to a TPM, so it cannot be lifted by ordinary user-level access. ### User store A user-store certificate belongs to the person. It is available only once that user logs on, so the port sits unauthenticated (or on whatever your failure posture is) until then. Crucially, unless the enrolment explicitly forbids it, the key may be **exportable**: the user, or anything running as the user, can copy the certificate and key to another machine. That machine now authenticates. You have paid the entire enrolment cost and produced a portable credential — better than a password, because copying takes deliberate action rather than reading a hash, but it is still a credential that can leave the device. ### What that means for the adversary - Machine-only admission: an attacker's laptop with the user's password, session cookies and even their exported user certificate is still refused, because the port wanted a device key it does not have. - User-only admission: whoever holds the exported key gets on, including a personal laptop the user brought in with entirely good intentions — which is the same admission decision with a different motive behind it. - Both, in sequence: the machine authenticates at boot and the user authentication replaces it at logon. If you accept either identity on its own, you have accepted the weaker one; getting a single decision that requires **both** an enrolled device and a valid user needs an EAP method that chains the two identities in one exchange, and the mechanics of that exchange belong to the RADIUS and EAP layer rather than to enrolment design. ## The chicken-and-egg, which is the actual deployment cost A brand-new device has no credential. With enforcement on, it cannot reach the network. Without the network, it cannot be enrolled. Every real programme resolves this in one of a few ways, and an interviewer will ask which one you chose: 1. **Pre-stage at build.** The device is enrolled during imaging or by the supplier before it ships, so it arrives with a machine credential. Cleanest, and it only helps devices you build. 2. **A dedicated onboarding path.** A restricted segment that exists solely to deliver a credential and reaches nothing else. It has to be genuinely narrow, because it is by definition a path that admits unauthenticated devices. 3. **Enrolment over another network.** The device gets its credential over a managed link and then meets the enforced ports already holding it. Whatever you choose, the enrolment path is now part of your admission perimeter. An automatic enrolment endpoint that will issue a network credential to anything that asks has not removed the front door, it has moved it — the strength of your admission is the strength of whatever authorises enrolment. The certificate authority's own issuance policy is a separate discipline; what belongs to you is the decision about who is allowed to ask. ## The line to give in an interview Machine store admits hardware you enrolled; user store admits whoever holds the key. Machine store is the stronger admission and the more expensive one, because it forces you to have a management channel to every device before enforcement day — and the devices you have no channel to are exactly the ones that will still be unenrolled the week you cut over.
- If both a machine and a user certificate exist, which one should the port's policy key on?Decide deliberately rather than accepting whichever arrives. If either identity alone is sufficient, your admission is only as strong as the weaker one — usually the exportable user key. Requiring both an enrolled device and a valid user needs an EAP method that chains the two identities in a single exchange; otherwise be explicit that you are admitting devices and treating the user identity as information, not as the gate.
- How do you enrol a device that has never been on the network?Pre-stage it. Enrol during imaging or have it arrive already carrying a machine credential, so it meets an enforced port with the key in hand. If you cannot build the device, you need a deliberately narrow onboarding path whose only reachable destination is the enrolment service — and you must count and review what uses it, because it is an admission route that skips your gate.
- Does an automated enrolment service weaken admission?It can. If anything that can reach the enrolment endpoint receives a network credential, admission is now decided by whatever authorises enrolment, not by 802.1X. Keep enrolment authorisation tied to something an attacker cannot present — a device already known to the management tool, a per-device secret, or a human-approved step — and treat the enrolment service as part of the admission boundary you review.
saying these in an interview costs you the question
- Thinks the store is a filing choice with no admission effect
- Assumes a certificate cannot be copied off a machine
- Cannot say which identity the authentication server sees
- Forgets a new device has no network to be enrolled over
- Treats an open onboarding segment as risk-free