## 2 Materials and Methods
### Mfa_R State Machines View
Once in the data waiting state (\(q5\)), already at the AUTH2 authentication level, the reputation system starts to be used. First, the device receives an initial reputation value (score), whereby the data publication evaluation process will be maintained. Thus, after the correct data publications (\(q11\)), the score is incremented (_increase_reputation_). Similarly, the reputation score will be decremented (_decrease_reputation_) if data publications are outside the configured standard (\(q7\)). As a result, following successive valid publications, the device reputation will pass the configured upper limit (_score \(>\) max_), and the device will be eligible (_raise_authlevel_) to level up (\(q12\)) via the _eventstep3_ok_. Additionally, as fault flows one can list (a) the reception of an invalid _auth_code_ and (b) the reception of invalid data. As such, when receiving an invalid _auth_code_ (a), the mechanism invalidates the access (_authcode_fail_) and evolves to the critical failure state (\(q8\)). On the other hand, when invalid data are received (b), the device's score is decremented. After successive publications of invalid data, the score will reach the lower reputation threshold, resulting in a request for enforcement. Also, if the enforcement is successful, the device will send data back to the system but with the authentication level AUTH2. However, if it is not in AUTH3 but rather AUTH2, the device will have its access invalidated (_invalidate_access_), reverting to the critical failure state (\(q8\)). Consequently, if enforcement fails, its state will devotive to critical failure (\(q8\)), and the device will exit the system. The next diagram is the **Sensor STM** (iii), which demonstrates the device lifecycle (Figure 6) and reflects the influence of the evolution of the authentication mechanism on the sensor. Even though some aspects of the sensor have already been covered in other diagrams, it is important to point out some facts discussed below. The sensor starts its life cycle without being registered (\(q0\)) and finalizes it in two ways: through critical failure (\(q2\)) or after its data-sending cycle (\(q7\)). It is worth noting that the device will only send data after successful second-factor authentication (_step2_ok_). It is also noteworthy that compatibility mode operation does not have a representation of internal states. Even without a representation of internal states, the mechanism needs to know all devices that are working in compatibility mode (\(q8\)). Figure 6: Sensor lifecycle state machine. It consists of eight states and 12 transitions. The diagram represents the sensor’s view of its internal state concerning the system and authentication mechanism. Lastly, there is the **authentication levels** STM (iv), which represents the evolution between the authentication levels (Figure 7). During the operation of MFA_R, its main objective is to more clearly show the essential steps for evolution in authentication levels and their order of occurrence. Also, it transparently represents the main failure flows that lead to a critical failure (\(q\)4). Subsequently, we can cite: failure in the first factor (\(step1\_fail\)), failure in the second factor (\(step2\_fail\)), failure in \(auth\_code\) (\(authcode\_fail\)), and access invalidation (\(invalidate\_access\)). Although a minor detail, it is important to note that there is no transition from failure to the third factor (reputation failure). A failure of this type can lead to enforcement, and it can result in a failure of the second factor during the enforcement process. As such, when authenticated at the AUTH3 level, a device eventually is removed from the system if it does not perform an enforcement correctly. This action prevents temporary read errors from taking the device out of the system. With the use of STMs, it was possible to detail the dynamic aspect of some components of the mechanism.