Sooner or later, you inherit an estate nobody can explain. The team that built it has left, the documentation is out of date, and you’re the one being asked whether it’s safe.
This session walks through how I approach that situation: what I do in the first ten days, how I turn what I find into decisions, and what I leave behind so the next person doesn’t have to start from scratch.
I’ll use a real example: two Azure tenants, eleven subscriptions, 63 storage accounts and 155 machines, with read-only guest access and nobody to ask for context. I’ll show how I collected the data, analysed it with AzureHound, and discovered that five service principals, identified only by hex strings, had access to every storage account in the estate.
I’ll also cover four times my own tooling gave me a clean, plausible answer that was wrong. When there’s nobody around to check your work, those are the mistakes you can easily miss.
You’ll leave with the scripts, a tool-by-tool guide to what each can tell you and where it can fail, and a blind-spot register that makes what you couldn’t verify an explicit part of the handover.
Takeaways
1. Now. Your survey is only as complete as your access allows. Agree the access you need before you start, and enforce scope in the code as well as in the statement of work.
2. Next. Once you’ve mapped the estate, you still need to decide what to do. Establish who owns each non-human identity before making changes, check every reported count against a second source, and record what you couldn’t verify in a blind-spot register.
3. Future. Handovers break down when the people who leave take their knowledge of ownership with them. Record ownership in metadata and enforce it through policy, manage non-human identities throughout their lifecycle, and set a minimum telemetry retention period. That gives the next person a graph they can work from, instead of a rumour.