Skip to content

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., your practice guide

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 Tool

Tier 1 · Web · No account

Version tested: Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-09. Date: 2026-09-09.

Open 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.

diagram.json

3,375 bytes · Circuit connections

Download

sketch.ino

11,956 bytes · ESP32 program

Download

  1. Use the launch button above to open the ESP32 editor in Wokwi.
  2. Select the editor’s diagram.json tab and replace all its text with the supplied diagram.json.
  3. Select the sketch.ino tab, replace all its text with the supplied sketch.ino, then click Start Simulation.

Steps

Screens captured against Wokwi ESP32 Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-09 on 2026-09-09; the tool may have moved on — the text steps are the contract.

  1. 1 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: LEDs, buttons, and buzzer connect to the ESP32. The ring marks the four LED and resistor paths.
    Step 1 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  2. 2 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: Locked: NO | Fails: 0 | Card: RFID_ADMIN_001 appears. The ring marks STATUS.
    Step 2 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  3. 3 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.
    Step 3: ACCESS GRANTED: Alice Admin - width= 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)
  4. 4 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: ACCESS DENIED: Eve Guest has GUEST, needs ADMIN appears. The ring marks the denial.
    Step 4 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  5. 5 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.
    Step 5: ACCESS GRANTED: Eve Guest - width= 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)
  6. 6 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: real Wokwi audit log shows 7058 ACCOUNT_DISABLED for Frank Former in Office Area with FAIL; the ring marks the row.
    Step 6 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  7. 7 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: The third unknown-card failure triggers BRUTE FORCE LOCKOUT. The ring marks the third failure and lockout.
    Step 7 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  8. 8 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: real Wokwi audit log shows 9567 ACCESS_BLOCKED/LOCKED_OUT and status Locked YES, Fails 3; the ring marks both rows.
    Step 8 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  9. 9 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: After lockout expires, Alice Admin is granted access again and STATUS reports Locked: NO, Fails: 0. The ring marks the restored grant and status.
    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.

  1. 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 check
  2. An 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

Caution

Use only the supplied fictional card IDs. This is a local teaching model: hardcoded cards, volatile logs, a shared lockout, and RESET are not production identity controls. The comparison still depends on input length and is not a vetted cryptographic primitive. Retain each LED resistor; briefly click buttons because holding Select cycles cards. USERS and ZONES are advertised by the source menu but are not implemented; use CARD, ZONE, STATUS, and LOG.

Return to IoT Access Control: Models and Policy · Browse Labs