20+ years in physical security. Now moving into cybersecurity.

I'm a 48-year-old career changer with over two decades of professional security experience — structural security, retail loss prevention, and cash-in-transit. After spending most of my working life protecting physical assets and people, I'm now studying Information Technology at Metropolia University of Applied Sciences and moving into cybersecurity.

Physical security and digital security turn out to share more than I expected. Both require thinking adversarially. Both require defence in depth. Both punish you for assuming users will behave the way you wish they would. The vocabulary is different; the discipline is the same.

The work you see here reflects that transition.

A privacy-first amnesic live operating system, built from scratch as my final-year project at Metropolia. Boots from a USB stick, routes every byte of traffic through Tor, forgets everything at shutdown.

• 8,800+ lines of Bash, one maintainable build script
• 50+ iterations with documented security audits between versions
• Four threat profiles for different user contexts
• Hardware-tested on real ThinkPad laptops, not just VMs
• Honest about what it doesn't protect against

If you're looking for an example of how I approach engineering — the project's development history walks through every wrong turn I took and what I learned from it.

An LLM-driven, human-in-the-loop penetration-testing assistant for Kali Linux. The Google Gemini API orchestrates dozens of standard security tools; I confirm every command that touches the "gray area" before it runs. My Innovation Project at Metropolia.

• Brain + Hands architecture — Gemini reasons over user intent, deterministic Python wrappers execute the actual commands
• Safety gate is in the code, not the model — a regex-based validator that classifies every command (hard-block / soft-block / per-tool risk level), layered on top of the LLM's own moderation rather than relying on it
• Two hardware profiles — field unit (X270, native Kali, monitor mode + injection) and compute unit (P1 Gen 5, WSL2 + RTX A3000, ~423 kH/s Hashcat against WPA handshakes)
• Decoupled HTML reporter — solves the token-window problem on large nmap/Wireshark outputs; ANSI color codes become real HTML so the report looks like a terminal, not an AI summary
• Verified end-to-end — full recon chain on real targets, ethical self-restraint on ambiguous ones, and a complete kill-chain on an intentionally-vulnerable IoT smart-home testbed
• Authorized use only — designed for labs, CTF, and engagements with written permission; the HITL prompts are not optional

For the full project vision and ethical rationale, see PROJECT_VISION.md (in Finnish).

Twenty years carrying responsibility for people's physical safety teaches you a few things:

• Threat modelling is not theory. Either your countermeasures work in the field or they don't.
• Layered defence is the only defence worth building. No single mechanism is the whole story.
• Documentation matters. When something goes wrong, somebody needs to understand what you set up and why.
• Honesty about limitations builds trust. Promising what you can't deliver is worse than promising less.

I'm bringing all of that to cybersecurity.

These are the tools I've actually used to build something real — not a list of buzzwords:

My focus is cybersecurity as a direct continuation of two decades in operational security — not software engineering for its own sake. The projects above are the technical means; the destination is security work.

• Penetration testing and offensive security — adversarial testing as a defensive discipline, the area my Gemini Pentest Pro project sits in
• Security operations — log analysis, alert triage, incident response, the cybersecurity continuation of an operations-centre career
• Vulnerability assessment and risk analysis — translating technical findings into operational risk that decision-makers can act on
• Physical-to-digital security continuum — insider threat, social engineering, red-team operations and physical penetration testing, where the operational security I built for a living translates most directly
• Threat modelling and defensive architecture — STRIDE, layered defence, fail-closed design as habits rather than checklists

I'm specifically interested in these roles, where my operational security background translates most directly:

Twenty years of shift work in cash-in-transit means I'm already used to operations-centre rhythms — long focus windows, alert handling under time pressure, clear escalation when something looks off. I'm building the technical layer (log analysis, SIEM concepts, incident triage) on top of that operational discipline.

Two decades watching the inside of high-value security operations means I know what abnormal behaviour actually looks like — not from a textbook, but from having walked past it. Behavioural baselines and policy violations were the language I worked in every day.

This one is obvious. I know how physical security is supposed to work because I built it for a living. I know where it tends to fail. I know the difference between a control that looks good on paper and one that holds up at three in the morning when nobody's watching.

Translating between operational reality and policy is something I did constantly in my previous career. Translating between technical risk and the way employees actually behave is the same skill in different clothes.

Career changers from operational security backgrounds aren't common in cybersecurity. The combination of two decades of adversarial thinking with the technical work you can see in this profile is unusual. If your team is hiring at the entry level and that sounds like a useful perspective, I'd be glad to talk.

I'm based in Finland, available for on-site or hybrid roles in the Helsinki region, and open to remote.

For project-related discussions, the best place is GitHub directly — issues, discussions, or via the noreply address used in my commits.

_{"Twenty years in physical security taught me that the best defences are layered, quiet, and honest about their limits.
The same is true in software. I'm building accordingly."}