I really just suggest avoiding TEAP if at all possible. I don't see how the method chaining helps anything. Doing both Machine and User auth is pretty pointless when both credentials are cached on the same machine. It's not like the user is prompted for an OTP, or some other method which proves that the user was present.
TEAP method change is just using *two* cached credentials instead of one. It offers no more security than using one cached credential.
I would like to implement EAP-TEAP because it should (theoretically) be possible that even if one of the two identities could not get verified (e.g., because there is no user certificate on the client yet), the server returns an Access-Accept, and depending on which of the two identities failed, the client is placed in a specific VLAN. If a user logs in to a client where only a machine certificate exists, the RADIUS server could detect this with the help of EAP-TEAP (because the user certificate does not exist and therefore no EAP-Identity is present) and the client could be placed in a network where it automatically receives the required user certificate. After receiving the certificate, a re-auth of the client would need to be performed so that it can be determined that both identities have been verified and the client can then access the internal company network. I tried to achieve this behavior by adding the custom EAP-TEAP configuration you provided to my FreeRADIUS and playing with the configuration a bit, but so far without success. Even if the FreeRADIUS server receives an "Unknown EAP-Identity" and then sends back an Access-Accept, the client remains disconnected from the network. Probably because the client only wants to connect to the network when both the server and the client have processed a "FreeRADIUS-EAP-TEAP-Result = Success". Do you plan on implementing this or is FreeRADIUS already capable of such behavior? And also, thank you for your help Alan. I really appreciate that.