const portfolio = { loading: true, status: 'initializing...'};
0%
Renan Rios — Product Designer, Product Builder & AI Orchestrator
back to home.tsx

~/case-studies/identity-security-posture

Identity Security Posture

Turning scattered identity signals into one prioritized recommendation, so admins can assess, understand, and strengthen their security at a glance.

From a one-week hackathon to Microsoft Entra Public Preview.

Lead Product DesignerMicrosoft Entra · ISPMIdentity
View the presentation

The demo tenant “Zava” and every figure in the walkthrough are mocked prototype data. No real customer, tenant, or employee data.

pipeline.tscode-native
PRD
Second brain
Research
Mocks · code
Prototype
Production
See the full process

00~/renan-rios$man identity-posture▋

What is identity security posture?

The idea in one minute: what identity posture is, what a “good state” means, and why closing that gap is the whole job.

Posture, in plain terms

Every company runs on thousands of accounts, from people to a growing number of apps and agents, and any one of them can become a way in. The clues are spread across half a dozen different security tools, so nobody sees the whole picture. Identity security posture pulls it all into one place, checks each account against its good state (the healthy setup expected for that kind of account) and shows how many accounts have reached it.

Why it matters: one hijacked administrator account can unlock the entire company. Turning security into a single, measurable good state, instead of a pile of alerts, lets someone see where things stand at a glance, act on the one change that helps most, and watch the number improve.

What a “good state” means

It's a plain pass/fail checklist, with no score and no partial credit. An account is either in good state, or it isn't.

What's on the checklist depends on the kind of account. For each thing that matters, from how strong the sign-in is to how much access it can keep to whether the device is trusted, accounts are held to a required level. The more powerful the account, the stricter the list: what's fine for an everyday login isn't fine for an app running in the background with broad access.

Administrators, for example

  • Sign-in that can't be phished
  • No always-on admin powers, granted only when needed
  • A healthy, company-managed device
  • No known risks left open
Break it down for meStill didn't get it? I'll give you an analogy

The home & keys analogy

Identity = who holds a key to your house. Family, a neighbor, the dog-walker, an old roommate who never gave theirs back.

Identity posture = the overall answer to “How safe is my house based on who can get in and how?” It's not one lock, it's the whole picture: how many keys exist, who has them, whether the doors are locked, and whether you'd notice if a stranger walked in.

Good state = the reassuring version of that picture:

  • Only people you trust have keys (no forgotten spare under the mat).
  • Everyone uses the deadbolt and the alarm code, not one alone (like requiring more than a password).
  • The old roommate's key was deactivated the day they moved out.
  • If someone jiggles the door at 3am, you get an alert instantly.

So identity posture in a good state means: the right people can get in, the wrong people can't, extra locks are in place, and anything suspicious gets noticed fast. You're not reacting to a break-in, you've already made one unlikely.

How this was solved before

There was no single place for it. People pieced the picture together by hand, a number from one tool, settings from another, with no shared definition of “healthy” to measure against. The closest thing was a single tenant-wide security score, useful, but one number for the whole tenant instead of a clear good state per kind of account. The teams who took it seriously had to build the missing parts themselves:

Build the groups by hand

Nothing sorted accounts for you. An admin hand-picked users one at a time from a spreadsheet-like table and built every group themselves.

Warn people by hand

No built-in way to warn people before a change took effect, so teams hand-built their own emails, timing and opt-outs.

Roll it out by hand

Every rollout, and every rollback, was manual. If something broke at 3 a.m., a person had to undo it by hand.

Identity security posture folds all of that into one connected loop, see where you stand, plan the change, fix it, with “good state” as the single yardstick.

v0~/renan-rios$git checkout v0-hackathon▋

v0 · The hackathon build

The hackathon proof: posture born inside the agent.

A hackathon build over a full week, in parallel with my day-to-day work. Identity posture lived inside the Conditional Access Optimization Agent as one more tab, with generic stat tiles and a suggested-cohorts donut. Enough to prove the concept had legs, on placeholder example data.

Process focusFramePrototype

How it began: one PM, an unusual ask

The spark

A hackathon, and an unusual ask

It began as a hackathon. A Product Manager on the Entra Conditional Access team came looking for someone who could design the experience and build it in code, and bring a rough idea to life. Over a single week, built in parallel with my day-to-day work, that became a working prototype, with identity posture living inside the Conditional Access agent.

The bet

The bet

The build drew attention from leadership, who asked us to keep going and shape it into something solid enough to put in front of customers. That greenlight turned a one-week prototype into a staffed effort on a path to Private Preview, and then Public Preview.

The team that formed

As lead designer I connected three PMs, engineering, and the wider Entra design org. Engineering converted my high-fidelity prototypes straight into the production codebase.

Three Product Managers

Each owned a slice: risky users and the posture dashboard; non-CA-policy phased rollouts and the customer-facing AI analysis; and agentic tenant analysis, the first-run experience, and break-glass. I designed across all three.

Engineering

Embedded throughout for technical input and feasibility. They took my high-fidelity prototypes and shipped them as production code.

IDNA design org

Weekly syncs with other IDNA designers to keep the work consistent with the broader Entra design language.

The operating rhythm

Daily syncs with PMs on open items

Bi-weekly feasibility syncs with engineering

Weekly demos

Leadership reviews roughly every three weeks

Weekly design-consistency syncs with other IDNA designers

The collaboration loop

collaboration.tshackathon loop
PM Mocks
PM/Design Sync
LLM discussion
Coded prototype
Engineering

A PM brought rough mocks; we synced on direction; then I worked through an LLM to turn it into a coded prototype, iterating until it was right, looping back with the PM before engineering built on it.

Where it started

Posture as a tab inside the agent: generic tiles, example data.
A basic cohort view inside the agent.
A basic rollout list, proof of the idea.

v0.5~/renan-rios$open second-brain-goodstate.netlify.app▋

The second brain behind every decision

Before a single Entra screen: a connected, private knowledge base of every PRD, meeting note, transcript, chat and research doc for this project. The single source the agents and I draw from.

One connected second brain

Every input for this work, from PRDs and meeting notes to call transcripts, customer research and my own chats with the agents, lives in one linked Markdown knowledge base. Instead of scattered files, it's a web of notes that Claude and the other agents read, write and synthesize as the design evolves.

It's also the paper trail. Every design change in v1 and v2 below traces back to a specific note in here: the decision, its source and its date.

PRDs · notes · transcriptsLinked & searchablePrivate & access-gatedAI reads · writes · synthesizes
Open the second brain · access-gated
second brain / graph205 notes · 210 links
PRDMeeting notesTranscriptsChatResearchPersonasFlows

v1~/renan-rios$git checkout v1-entra▋

v1 · The Entra baseline

Consistent with Entra, and, in one review, called dull.

Rebuilt as a first-class Identity posture surface using current Entra components and styles. Correct, consistent, and legible, but built from dense tables and standard cards. In a leadership review the feedback landed hard: it looked like every other settings page.

Process focusSecond brainExplorePrototype
Every change is backed by a decisionCustomerLeadershipDesign sourced from the second brain

What changed & why

Posture overview

v0 · before

Posture as a tab inside the agent: generic tiles, example data.

v1 · after

A standalone surface, but still a dense metrics-and-table layout.

Segment / cohort detail

v0 · before

A basic cohort view inside the agent.

v1 · after

A structured assessment drawer, in standard Entra styling.

v2~/renan-rios$git checkout v2-shipped▋

v2 · The AI-forward redesign

What shipped, after customer, leadership & design feedback.

The redesign that leadership and customers loved. A narrative, AI-forward experience: one headline insight, a “meeting good state” trend, a prioritized recommended-actions list, human-initiated rollout waves, and tenant-shaped customization, every move traceable to a decision.

Process focusResearchExplorePrototypeHandoff

What changed & why

Posture overview

v1 · before

A standalone surface, but still a dense metrics-and-table layout.

v2 · after

A narrative, AI-forward read: one insight, a trend, prioritized actions.
Leadership

From settings page to AI narrative

Replaced the metrics-grid-plus-table with a narrative hero: a single headline insight (“your privileged tier is the biggest opportunity”), tenant-context chips, and compliance framing.

Decision: Leadership wanted the experience to feel AI-driven rather than like another Entra settings page. This kicked off the whole redesign.

second-brain · Leadership · AI-Driven Good State brainstorm · Apr 2026
Leadership

A “good state” you can watch move

Added a “meeting good state” headline metric with a six-analysis trend line and a target, so progress is visible over time.

Decision: Admins needed to see posture improving, not a static score; the good-state framing made the outcome legible.

second-brain · Leadership · Good State phase-2 review · Apr 2026

Segment / cohort detail

v1 · before

A structured assessment drawer, in standard Entra styling.

v2 · after

Reframed around end-states and the admin's job-to-be-done.
Design

Controls read as end-states

Rewrote the drawer around outcome-framed states (“No standing privilege”, “Phishing-resistant MFA only”, “No open risk”), consistent from hero to drawer.

Decision: Jobs-to-be-done research showed admins think in target end-states, not raw control names, so the whole IA was aligned to outcomes.

second-brain · Design · Posture-page JTBD redesign spec · Jun 2026

Phased rollout

v1 · before

Functional phased rollout, standard components.

v2 · after

Human-initiated waves, an impact preview, visible safeguards.
Customer

Human-initiated, reversible waves

Rebuilt the rollout as phased waves that each start only when an admin clicks Start, with an impact preview and one-click pause-and-restore, and no silent auto-enforcement.

Decision: Auto-enforcement is a non-starter in change-controlled orgs; trust has to be earned with visible guardrails before anything is automated.

second-brain · Customer · Private Preview change-control feedback · May–Jun 2026
Customer

Break-glass, made real-world

Reworked break-glass handling to auto-detect and exclude emergency-access accounts (group-based too), removing rigid Global-Admin assumptions and the dead-ends they created.

Decision: A Private Preview customer showed that rigid Global-Admin assumptions broke how real tenants run emergency access.

second-brain · Customer · Break-glass customer sync · Apr 2026

Customization (new in v2)

v2 · new
A settings suite plus new-segment wizard, net-new in v2.

~/renan-rios$git push origin main▋

Hand off through the repo

The prototype and the product were the same codebase, so handoff was a merge, not a rebuild.

One repo, zero translation

Because the prototypes were production-grade code, engineering never rebuilt from a picture. They took the same components and shipped them. The design couldn't drift from what launched, because they were the same thing.

  • High-fidelity prototypes authored as real, typed components
  • Engineering converted them directly into the production codebase
  • No redlines and no lossy translation between design and build
  1. 01

    One-week prototype

    Hackathon

    A working build, designed and coded in a week alongside my day-to-day work.

  2. 02

    Shipped to real enterprises

    Private Preview

    Three preview phases cleared; prototypes became production code.

  3. 03

    Shipping next

    Public Preview

    Rolling out to Microsoft Entra Public Preview.

~/renan-rios$cat ./retro/reflection.md▋

Reflection

What this project says about how I work, and where it goes next.

The takeaway

A design-and-code force multiplier who turns AI ambiguity into trustworthy, shipped product.

  • Prioritization is the product: the highest-value move was collapsing scattered signals into one recommendation an admin could trust.
  • Trust is a design material: guardrails, impact previews, and human-initiated action earn the right to automate.
  • Designing in code closed the gap between intent and production; engineering shipped what I prototyped.
  • The "make it feel AI-driven" challenge pushed my craft further than any written brief could.

What's next

Public Preview is next, with scope reaching toward non-human and agentic identities, deeper compliance mapping, and posture that spans platforms.

// end of case study

Want the rest of the story?

Explore the six-step process behind this work, see more Microsoft Entra work, or head back home.

My design process Delivery recordBack to home.tsx