A security-first IoT vault as an integration project

The Impenetrable 2

An end-to-end IoT prototype combining a physical ESP32 vault, a secured web application, real-time events, database integrity and cloud deployment.

Security Engineer, Data Engineer and integration support

Next.js
React
TypeScript
Java 21
Spring Boot
PostgreSQL
Flyway
Socket.IO
ESP32
Docker
OpenShift
OWASP ZAP

Vault detail · access, ownership and hardware events come together in one secured flow.

Context: UCLL bachelor integration project
Team: Team of six
My role: Security Engineer, Data Engineer and integration support
Stack: Next.js, Spring Boot, PostgreSQL, Socket.IO, ESP32, Docker and OpenShift
Experience: OAuth2, TOTP MFA, CSRF/CORS, Flyway, WebSockets and security scans

Project and context

The Impenetrable 2 was a bachelor integration project in which six students connected a physical vault to a full-stack web platform. Users could pair a vault, share access, manage requests, change PIN codes and monitor security events in real time.

From physical vault to working demo

The project was not just a website or a hardware demo. The demonstration brought together an ESP32 setup with keypad, display and status LEDs with the web application that made vault status and events visible.

Physical prototype of The Impenetrable 2 with keypad, display and status LEDs. — Physical prototype · keypad, display and status LEDs make the IoT layer tangible.

Demo setup with opened vault, ESP32 electronics and web application. — Event demo · the physical setup and web app were demonstrated together.

Access, ownership and real-time events

The vault detail page shows the core product flow: pending access requests, active key holders, hardware ID, PIN-code management and a chronological event log with notifications from the physical vault.

The Impenetrable 2 vault detail page with access request, active key holders and real-time activity. — Vault detail · access, ownership and hardware events come together in one secured flow.

Vault detail after Jane Doe became owner and no pending request remains. — Ownership transfer · shared access can become new ownership.

Secure pairing between account and hardware

An owner pairs a new vault through a hardware ID and temporary screen code. The backend guards the expiry time, validates the request and connects the physical vault to the correct account.

Pairing wizard with temporary four-digit screen code and countdown timer. — Pairing · a temporary code connects the physical vault to the correct account.

Administration and data insight

The admin dashboard visualises users, registered hardware, notification types, high alerts and activity over time. This turned the raw event flow into something usable for control and analysis.

Admin dashboard with KPIs, filters, activity trend, charts and vault overview. — Admin dashboard · events become usable as KPIs, filters and visualisations.

My role

My focus was mainly security and data engineering. I worked on Google OAuth2, TOTP MFA, JWT cookies, CSRF/CORS, security headers, Flyway, PostgreSQL production configuration, a stored procedure for atomic access management and OWASP ZAP scans in CI/CD.

Main challenge

The main challenge was that several layers had to work correctly at the same time: hardware events, WebSockets, API security, database integrity, frontend state and OKD deployment. I helped narrow down issues, review pull requests, resolve merge conflicts and verify fixes again in the shared environment.

Result

The result was an extensive working prototype with physical hardware, real-time monitoring, shared access, admin insights and automated security checks. This case mainly shows that I look beyond isolated features and care about reliability across the whole system.