Is it possible to use 802.1x in a cisco catalyst switch without external radiusserver?

I have a usecase where 802.1x is wanted but the switch the clients connects to will not be able to reach an external radiusserver for authentication of the clients.

Is it somehow possible to configure a local "radiusserver" in a modern cisco catalyst switch or is there some other trick available to use 802.1x along with guestvlan which then is switched into a prodvlan once the client is authenticated?

The authentication in this case is fine if its just based on mac address (will still apply port-security so not any box will be able to be plugged into these switches) but something like EAP-MD5 would be fine too because Im not expecting to be able to do cert-based authentication at this point (unless there is a method for this available without an external radiusserver?).

This deployment guide mentions MAB (MAC Authentication Bypass) but that still seems to require an external radiusserver, however the below is mentioned so Im hoping somebody in here might already experimented with this and can point to some example configs or such?

https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/config_guide_c17-663759.html

2.4.6 Inaccessible RADIUS Server

When the RADIUS server is unavailable, MAB will fail and, by default, all endpoints will be denied access. In a highly available enterprise campus environment, it is reasonable to expect that a switch will always be able to communicate with the RADIUS server, so the default behavior may be acceptable. However, there may be some use cases (for example, a branch office with occasional WAN outages) in which the switch cannot reach the RADIUS server, but endpoints should be allowed access to the network.

If the switch already knows that the RADIUS server has failed (either through periodic probes or as the result of a previous authentication attempt), a port can be deployed in a configurable VLAN (sometimes called the critical VLAN) as soon as the link comes up. Because the switch has multiple mechanisms for learning that the RADIUS server has failed, this outcome is the most likely. If the switch determines that the RADIUS server has failed during a MAB authentication attempt (for example, if this is the first endpoint to connect to the switch after connectivity to the RADIUS server has been lost), then the port will be moved to the critical VLAN after the authentication times out. Previously authenticated endpoints will not be affected in any way; if a reauthentication timer expires when the RADIUS server is down, the reauthentication will be deferred until the switch determines that the RADIUS server has returned.

When the RADIUS server returns, the switch can be configured to reinitialize any endpoints in the critical VLAN. This behavior poses a potential problem for a MAB endpoint. When the MAB endpoint originally plugged in and the RADIUS server was unavailable, the endpoint received an IP address in the critical VLAN. Because the MAB endpoint is agentless, it has no knowledge of when the RADIUS server has returned or when it has been reinitialized. If the device is assigned a different VLAN as a result of the reinitialization, it will continue to use the old IP address-an IP address that is now invalid on the new VLAN.

There are several ways to work around the reinitialization problem. You can disable reinitialization, in which case, critical authorized endpoints will stay in the critical VLAN until they unplug and plug back in. You also can set the critical VLAN to the data VLAN (essentially a fail-open operation) so that the MAB endpoints maintain a valid IP address across reinitialization. If neither of those options is feasible, consider setting the DHCP lease time in the critical VLAN scope to a short time (for example, 5 minutes) so that a MAB endpoint will have an invalid address for a relatively short amount of time.

Would for example this be a doable workaround for such usecase as described in https://services.geant.net/sites/cbp/Knowledge_Base/Security/Documents/gn3-na3-ufs_133.pdf ?

authentication event fail action authorize vlan <vlan-nr> authentication event server dead action authorize vlan <vlan-nr> authentication event no-response action authorize vlan <vlan-nr> 

along with lowered timers:

dot1x timeout quiet-period <sec> ! default value 60 dot1x timeout tx-period <sec> ! default value 60 dot1x timeout supp-timeout <sec> ! default value 60