Test role access and inspect the audit log
Compare admin, guest, disabled, and unknown cards against zone permissions and verify the audit reason for each decision.

Shield Shelly: I want you to check who was recognized, what was allowed, and which audit entry proves it.
Predict the reading, then compare it with the measurement.
Wokwi ESP32
Third party ToolOpen the ESP32 editor, paste diagram.json, then paste sketch.ino.
Open Wokwi to paste in the files (new tab)Get the files
Use both prepared files. This is a paste-in setup; saving a project requires a Wokwi account.
sketch.ino
- Use the launch button above to open the ESP32 editor in Wokwi.
- Select the editor’s diagram.json tab and replace all its text with the supplied diagram.json.
- Select the sketch.ino tab, replace all its text with the supplied sketch.ino, then click Start Simulation.
Steps
Step 1
- Do
- In Wokwi's project editor, paste diagram.json and sketch.ino into a new Wokwi ESP32 project; inspect the seven GPIO connections before starting.
- You will see
- LED 0 anode connects to ESP32 GPIO2 and returns through r0 to ground (diagram.json lines 129, 141). LED 1 anode connects to ESP32 GPIO4 and returns through r1 to ground (diagram.json lines 147, 159). LED 2 anode connects to ESP32 GPIO5 and returns through r2 to ground (diagram.json lines 165, 177). LED 3 anode connects to ESP32 GPIO18 and returns through r3 to ground (diagram.json lines 183, 195). Buzzer pin 2 connects to ESP32 GPIO19; pin 1 returns to ground (diagram.json lines 201, 207). Select-card button connects ESP32 GPIO15 to ground when pressed (diagram.json lines 213, 219). Request-access button connects ESP32 RX2/GPIO16 to ground when pressed (diagram.json lines 225, 231).
- Why it matters
- The four LED paths and buzzer expose later access decisions. The two grounded button inputs initiate card selection and access requests for the audit sequence.

Step 1 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 2
- Do
- In the Simulation toolbar, start the run; send STATUS in the Serial Monitor input field.
- You will see
- Input: send STATUS after startup. Observed: "IoT ACCESS CONTROL SYSTEM v1.0". Observed: "Locked: NO | Fails: 0 | Card: RFID_ADMIN_001". Expected: an unlocked baseline with zero failures.
- Why it matters
- The startup heading identifies the running sketch. The lockout state is NO. The failure counter is zero. The selected card is the admin fixture.

Step 2 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 3
- Do
- In the Serial Monitor input field, send CARD 0 and then ZONE 2.
- You will see
- Input: CARD 0, then ZONE 2. Observed: "Card: RFID_ADMIN_001 -> Zone: Server Room (Requires: ADMIN)". Observed: "ACCESS GRANTED: Alice Admin -> Server Room". Expected: the admin fixture may enter the server room.
- Why it matters
- The request states the ADMIN requirement. The selected card is the admin fixture. The decision is explicitly GRANTED. The output names the requested zone.
Server Room appears. The ring marks the admin grant." loading="lazy">Step 3 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 4
- Do
- In the Serial Monitor input field, send CARD 2 and then ZONE 2.
- You will see
- Input: CARD 2, then ZONE 2. Observed: "Card: RFID_GUEST_001 -> Zone: Server Room (Requires: ADMIN)". Observed: "ACCESS DENIED: Eve Guest has GUEST, needs ADMIN". Expected: the guest is denied for an admin zone.
- Why it matters
- The card switched to the guest fixture. The requested zone still requires ADMIN. The output names the role mismatch. The result is a denial rather than an access grant.

Step 4 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 5
- Do
- In the Serial Monitor input field, keep CARD 2 and send ZONE 0.
- You will see
- Input: CARD 2 remains selected; send ZONE 0. Observed: "Card: RFID_GUEST_001 -> Zone: Public Lobby (Requires: GUEST)". Observed: "ACCESS GRANTED: Eve Guest -> Public Lobby". Expected: the same guest may enter the public lobby.
- Why it matters
- The guest role is sufficient for this zone. The request names the GUEST requirement. The decision changes to GRANTED. Comparing both zones shows a role based decision.
Public Lobby appears. The ring marks the scoped guest grant." loading="lazy">Step 5 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 6
- Do
- In Wokwi's Serial Monitor, send CARD 3, then ZONE 1, and finally LOG.
- You will see
- Input: send CARD 3, ZONE 1, and LOG in Wokwi Serial Monitor. Observed audit row: " 7058 | ACCOUNT_DISABLED | Frank Former | Office Area | FAIL". Observed earlier: the admin and guest entries have their own decisions. Expected: the disabled credential is denied for Office Area.
- Why it matters
- The row names the disabled-account reason. Frank Former is the named fixture in this run. The event is marked FAIL, not a grant. The timestamp 7058 belongs to this capture and may vary on another run.

Step 6 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 7
- Do
- In the Serial Monitor input field, send CARD 4 and ZONE 2 three times.
- You will see
- Input: unknown CARD 4, then three ZONE 2 requests. Observed: "AUTH FAILED: Unknown card (3/3)". Observed: "!!! BRUTE FORCE LOCKOUT !!!". Expected: the third failure trips the lockout.
- Why it matters
- The failure counter reached its threshold. The third request still used an unknown card. The lockout announcement follows that failure. A later request must be checked separately for blocking.

Step 7 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 8
- Do
- In Wokwi's Serial Monitor, during lockout, send CARD 0 and ZONE 2; then send LOG and STATUS.
- You will see
- Input: after three unknown-card failures, send CARD 0, ZONE 2, LOG, and STATUS. Observed audit row: " 9567 | ACCESS_BLOCKED | LOCKED_OUT | Server Room | FAIL". Observed status: "Locked: YES | Fails: 3 | Card: RFID_ADMIN_001". Expected: the admin credential remains blocked during lockout.
- Why it matters
- The selected card is the valid admin fixture. The gate blocks it because the system is locked. LOG records ACCESS_BLOCKED with LOCKED_OUT as the reason. The audit timestamp 9567 is specific to this real run.

Step 8 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 9
- Do
- In Wokwi's Serial Monitor, wait at least 60 simulated seconds for Lockout expired -- system unlocked.; send CARD 0 and ZONE 2 again.
- You will see
- The admin request is granted again. STATUS reports Locked: NO and Fails: 0.
- Why it matters
- Time and state change the result. This local cooldown illustrates contextual enforcement but does not implement a general ABAC engine.

Step 9 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
Chapter checks
These questions refer to the chapter’s examples. Use the return links to review their answers.
A new technician account is created in an IoT platform. Following least privilege, what should its initial access be?
Return to the chapter’s knowledge checkAn AWS IoT-style policy contains a broad statement that Allows publishing to all device topics and a separate statement that explicitly Denies publishing to another tenant's topics. A device tries to publish to another tenant's topic. What happens?
Return to the chapter’s knowledge check
Return to IoT Access Control: Models and Policy · Browse Labs