Zero Trust Foundations: Running AAVI Through the Identity Pillar

Why documenting transaction flows and Zero Trust policy statements comes before pillar-by-pillar assessment, and how Identity becomes the first participant in the trust decision.

Summary: This week we begin applying AAVI to the first Zero Trust pillar: Identity. Before we do, we slow down and document the transaction flows and Zero Trust policy statements for our protect surface. Those statements become the operating target for every pillar. Identity may be where Zero Trust starts, but it cannot be treated as a stand-alone project. Each pillar participates in the larger security architecture and contributes evidence to the trust decision.

Grab a fresh cup of coffee and let’s roll up our sleeves. In the last post, we introduced AAVI: Assess, Adapt, Verify, and Iterate. That gave us a repeatable way to move an existing environment toward functional Zero Trust without pretending the mess does not exist. This week, we begin the first pillar pass with Identity.

Here is the roadmap for this cup: first we document the transaction flows, then we turn those flows into Zero Trust policy statements, then we run Identity through AAVI, and finally we check whether the cross functions can prove, apply, and govern the decision. If that sounds like a lot, do not worry. We are not drinking the whole pot at once. We are taking one practical sip at a time, in the order the architecture needs.

Before we start inspecting identity controls, groups, roles, MFA, service accounts, and privileged access, we need to do something more basic and more important: document the transaction flows and write the Zero Trust policy statements that describe what should happen. Otherwise, we risk tuning identity controls without knowing which trust decision they are supposed to support, which is a little like reorganizing the coffee bar before deciding whether anyone ordered coffee.

Start With the Transaction Flows

A Zero Trust conversation gets fuzzy fast when we talk about applications in the abstract. “Protect the business application” is too broad. “Secure the database” is too incomplete. “Require MFA” is useful, but it does not tell us which action we are trying to control or what other signals should participate in the decision.

That is why we start with transaction flows. For our messy hybrid business application, the protect surface includes the on-premises application, the legacy database, SaaS analytics, cloud file storage, administrative tools, vendor support access, service accounts, and customer records. The important question is not only what exists. The important question is how trust moves through it.

A practical first pass might document these flows: a finance user signing in and viewing customer records, an operations user exporting a report to SaaS analytics, a service account moving data between systems, an administrator changing application configuration, a customer support user copying a file to cloud storage, and a vendor connecting for support. Each flow should describe who or what acts, what action is requested, what data or system is touched, where the transaction travels, why the action exists, and how the decision should be enforced and logged.

A simple way to keep the conversation grounded is to document each flow using the same pattern: actor, action, protect surface, identity signal, related pillar signals, enforcement point, and verification evidence. For example, a finance user exporting customer records should identify the named user, the export action, the customer-record protect surface, the required MFA or step-up signal, the managed-device requirement, the approved application workflow, the data-handling rule, and the logs that prove the decision later. That structure turns the transaction from a vague security discussion into something each team can test against.

Write the Zero Trust Policy Statement Before You Evaluate the Pillar

Once the transaction is understood, we turn it into a Zero Trust policy statement. This is not legal language and it is not vendor configuration syntax. It is a plain-English design target. It describes the intended behavior clearly enough that identity, device, network, application, data, security operations, governance, and business owners can all test their part against the same expectation.

For the report export flow, a first policy statement might read like this: an authorized finance or operations user may export approved customer reporting data from the business application to the SaaS analytics platform only through the approved application workflow, using a named identity, from a managed and compliant device, when the user role permits export, session risk is acceptable, sensitive data handling rules are applied, and the export is logged with enough detail to reconstruct the decision later.

A useful shortcut is to write each policy statement in the same pattern: who may do what, to which protect surface, under which conditions, through which path, with what enforcement, and with what evidence. If the sentence cannot answer those questions, the control teams will fill in the blanks differently. That is how five reasonable people end up implementing five different versions of the same policy, usually before the coffee is even cool enough to drink.

For administrative configuration changes, the statement might be tighter: an approved administrator may change production configuration only through the authorized management path, using strong authentication and time-bound privileged access, from an approved administrative device, with an associated change record, logged session activity, and a tested rollback path.

Those statements matter because they become the standard for AAVI. They keep us from asking whether Identity looks mature in isolation and force us to ask the better question: can Identity participate in these specific trust decisions with enough confidence, evidence, and control to change the outcome when conditions are wrong?

No Pillar Gets to Be a Stand-Alone Effort

This is where teams can accidentally drift off course. It is tempting to run AAVI for Identity as if Identity were the whole Zero Trust project. Inventory the accounts, clean up a few groups, require MFA, reduce some admin rights, and call the pillar done. Those are good improvements, but they are not the same thing as Zero Trust.

The AAVI pass for each pillar cannot be viewed as a stand-alone effort. Each pillar is part of the whole Security Architecture picture, and each pillar participates in the trust decision. Identity answers who is making the request. Device answers whether the endpoint or workload is trustworthy enough under current conditions. Network answers how far the session should reach. Application answers what action is being attempted. Data answers what is at stake. Visibility proves the decision. Automation helps apply it consistently. Governance keeps it from drifting back into assumption.

Zero Trust is an operating system and a discipline. It is not any single pillar, product, feature, or capability. If we optimize Identity in a vacuum, we may make login stronger while still allowing broad exports, unmanaged devices, flat network paths, weak application roles, and sensitive data movement with little consequence. That is better authentication, not functional Zero Trust.

AAVI Through the Identity Pillar

Identity is where Zero Trust starts, not because identity is perfect or complete, but because every trust decision begins with the same basic question: who is making the request? That answer gives the rest of the architecture something to reason from, but it does not settle the decision by itself. A known identity on an unhealthy device, using an unexpected path, attempting a high-risk action against sensitive data, may still deserve a challenge, limit, or denial. Identity opens the conversation. The full architecture decides whether the request earns trust.

The good news is that most organizations already have reasonably strong identity tooling in place. Directory services, single sign-on, MFA, role assignments, lifecycle processes, and privileged access tools are common. The problem is rarely the absence of identity controls. The problem is whether those controls are enforced consistently, connected to the transaction, and treated as ongoing decision inputs instead of a one-time login gate.

Assess: Where Does Identity Participate Today?

In the Assess step, we inventory the identities and identity paths that touch the protect surface. That includes workforce users in finance, operations, and customer support; administrators; vendors; service accounts; workload identities; application registrations, API clients, managed identities, automation or bot identities, AI agents, AI assistants, autonomous workflow identities, model API identities, machine identities, certificates, secrets, tokens, local application accounts, cloud identities, and any side doors that can authenticate without the main identity provider.

For our example protect surface, we may already be in decent shape in some places. Users authenticate through the corporate identity platform. MFA may already be enforced for most employees. Finance and operations may already have distinct groups. Administrators may already have separate accounts. These are areas where Zero Trust is achievable with what is already there, if the controls are connected to the transaction policies and not treated as generic security hygiene.

Assessment will also expose work still to be done. The application may have local accounts left over from an earlier era. A vendor support account may be shared or long-lived. Service accounts may have no clear owner. Export permissions may be granted through broad legacy roles. Administrators may have standing privilege instead of time-bound elevation. MFA may be enabled but not enforced for every protect-surface user or high-risk action. Legacy authentication may still exist for compatibility, quietly bypassing modern controls. Each one is a place where identity is being treated as entitlement instead of evidence.

Non-human identity gaps deserve special attention because they often bypass the habits we use for people. A user eventually leaves a team, changes roles, or shows up in an access review. A service account, API token, automation identity, AI agent identity, AI assistant connection, application registration, certificate, or managed identity may keep working quietly for years. That does not make it safe. It just means the coffee mug has been sitting there so long that everyone assumes it belongs to someone.

Adapt: Turn Identity Into Decision Authority

In Adapt, we use what already exists to make identity more intentional and bounded. The goal is not to replace the identity platform. The goal is to make the existing identity systems behave as policy authority, not just authentication service.

For routine application access, that may mean enforcing MFA for all users in the protect-surface population, removing local user accounts where corporate identity can be used, cleaning up role membership, and documenting which groups map to which business actions. For export actions, identity should distinguish between users who may view records and users who may export them. For administrative changes, identity should require stronger assurance, time-bound elevation, and clear linkage to an approved change.

This is also where we begin closing identity escape hatches. MFA exceptions need owners and expiration dates. Legacy authentication needs a retirement plan. Shared accounts need a path to named accountability. Non-human identities need the same discipline: service and workload identities need owners, scoped permissions, credential rotation, expected behavior, monitoring, and retirement criteria; application registrations, API clients, AI agents, AI assistants, autonomous workflow identities, and model API identities need least-privilege scopes, secret or certificate hygiene, permission review, prompt/data boundary review where applicable, and clear linkage to the business process they support. Standing administrator access should shrink as privileged activity moves toward just-in-time and just-enough access.

Critical Identity Controls: MFA and Legacy Authentication

Two identity controls deserve a bright yellow sticky note on the coffee pot: multi-factor authentication and legacy authentication protocols. If those two are weak, everything else in the Identity pillar has to work uphill. MFA raises confidence in the human request. Legacy authentication, when left enabled, quietly lowers that confidence by giving attackers an older side door around modern policy. One is the seatbelt. The other is the missing door latch. You can still drive that way, but nobody should call it safe.

MFA must be enforced, not merely available. Plenty of organizations can say MFA is enabled. That is not the same as saying MFA is required for the people, applications, and actions that matter. For our protect surface, MFA should be enforced for every user population that touches the application, with stronger or phishing-resistant methods expected for administrators, high-risk roles, vendor access, and sensitive actions such as export or configuration change. Exceptions should be rare, owned, documented, time-bound, and reviewed. If an exception does not have an expiration date, it is not an exception; it is a permanent policy gap wearing a fake mustache.

It also helps to separate MFA coverage from MFA assurance. A push notification, a one-time code, and phishing-resistant authentication do not provide the same level of confidence. For routine access, broadly enforced MFA may be enough to move the protect surface forward. For administrators, vendors, privileged elevation, bulk export, or configuration changes, the stronger standard should be phishing-resistant authentication where practical, or a clearly documented compensating control where it is not yet available. The point is not to shame the current method. The point is to match authentication strength to action risk.

For non-human identities, including AI identities, the equivalent question is not MFA, but assurance. How is the workload, application, script, service, AI agent, AI assistant, or model API proving it is the expected actor? Is it using a managed identity, certificate, short-lived token, signed workload identity, scoped API credential, or a long-lived secret copied into a configuration file three years ago? Human identities need strong authentication; non-human and AI identities need strong, owned, scoped, rotated, and observable credentials that can participate in policy decisions and produce evidence.

Legacy authentication protocols must be identified and retired. Basic authentication, older mail protocols, outdated password-based flows, legacy NTLM patterns, and application paths that cannot participate in conditional access or step-up decisions are not just old technology. They are trust bypasses. They collapse the decision back to “did the password work?” and ignore the signals Zero Trust depends on: MFA strength, session risk, device posture, conditional access, token controls, and action sensitivity. Attackers do not need to defeat the strongest path if the weakest path is still open.

In AAVI terms, Assess asks where MFA is enforced and where legacy authentication still appears in sign-in logs. Adapt makes MFA the default and starts retiring legacy protocols in waves, beginning with privileged users and protect-surface applications. Verify proves that sensitive transactions actually required MFA or step-up and that legacy authentication usage is trending down. Iterate keeps reducing implicit trust until the old paths are gone or explicitly isolated with compensating controls and visible ownership.

A practical retirement sequence keeps this work from becoming an all-or-nothing argument. First, measure where legacy authentication is still being used. Second, identify the users, applications, scripts, service accounts, and vendors behind those sign-ins. Third, classify each use case as removable, migratable, or temporarily tolerated with compensating controls. Fourth, block legacy authentication for privileged identities and the protect surface first. Fifth, review usage after each wave until the remaining exceptions have named owners, expiration dates, and an exit plan. If nobody owns the exception, the exception owns you.

The important warning is this: do not let legacy authentication retirement become only a protocol cleanup project. The real goal is to remove any authentication path that cannot participate in the trust decision. If a path cannot enforce MFA, evaluate risk, honor conditional access, support step-up, or produce usable evidence, it should be treated as Zero Trust technical debt until it is removed or tightly contained.

Non-Human Identities: The Quiet Majority of Identity Risk

When we say Identity, we should not only picture a person typing a password. In modern environments, non-human identities often outnumber human users and may touch the protect surface more often. They include service accounts, workload identities, managed identities, application registrations, API clients, automation accounts, bots, CI/CD pipeline identities, database accounts, machine identities, certificates, secrets, keys, tokens, AI agents, AI assistants, autonomous agents, model API identities, retrieval connectors, and AI workflow identities. Each one can request access, move data, change configuration, call tools, retrieve documents, summarize records, or connect systems together. That makes each one a participant in the trust decision.

The assessment question for non-human identities is simple: can we explain what this identity is, who owns it, what it is allowed to do, where it is allowed to run, what credential it uses, how long that credential lives, what normal behavior looks like, and what should happen when it behaves differently? If the answer is “it runs the job,” we are not done. That is a job description written on a napkin.

AI identities need their own line in that catalog. An AI assistant that can query customer records, an autonomous agent that can trigger workflows, a model API identity that can call enterprise tools, or a retrieval connector that can read internal documents is not just a feature. It is an actor. It should have an owner, scope, approved tools, approved data sources, logging, prompt and action boundaries, credential strategy, review cadence, and a clear kill switch. If an AI identity can act, retrieve, summarize, recommend, or initiate work, it belongs in the identity inventory, not in the “we will figure that out later” drawer.

A practical non-human identity catalog should include at least the identity name, type, owner, business purpose, protect surface touched, permissions or scopes, credential type, credential age, rotation method, expected source, expected destination, expected schedule, logging location, review cadence, and retirement trigger. For AI identities, also capture approved tools, approved data sources, model or agent purpose, prompt and action boundaries, allowed retrieval scope, human approval requirements, and emergency disablement path. That may sound like a lot, but it is still easier than explaining during an incident why a forgotten token or over-permissioned AI connector could export customer records at 2:00 a.m.

Verify: Prove Identity Changed the Decision

Verify is where we stop accepting good intentions as evidence. If a finance user exports a report, can we prove the named identity was used, MFA was enforced, the role permitted export, session risk was acceptable, and the export action was logged? If an administrator changes configuration, can we prove privileged access was activated temporarily, strong authentication occurred, the admin used the approved path, and the session can be reconstructed later?

Some evidence may already be available from the identity provider, access logs, privileged access tools, application logs, and change records. That is where Zero Trust is achievable with the tools already in place. But verification may also reveal gaps: logs may show sign-in but not authorization, service account activity may not be tied to a business owner, local application roles may not map cleanly to enterprise groups, or MFA may be visible at login but not tied to the higher-risk action that followed.

For Identity verification, the minimum evidence set should include the named identity, whether it is human, non-human, or AI-driven, authentication method or credential type, MFA or step-up result for human users, credential or token validation for non-human and AI identities, sign-in, workload, or agent risk, role or group that authorized the action, delegated permission or tool scope if applicable, privileged elevation state if applicable, legacy authentication status, session or transaction identifier, application action tied to the identity decision, and the final allow, challenge, limit, or deny outcome. If those records live in five places, that may be normal early on. If nobody can stitch them together, that is the gap to fix next.

Iterate: Keep Identity From Drifting Back

Iteration is where identity work becomes discipline. Access reviews should remove permissions, not just confirm them. Non-human identities should not become immortal. Service accounts, workload identities, API clients, application registrations, AI agents, AI assistants, model API identities, retrieval connectors, certificates, secrets, keys, and tokens should be reviewed, rotated, scoped, monitored, and retired when no longer needed. Privileged roles should shrink over time. Legacy authentication usage should trend toward zero. The goal is not to make identity perfect. The goal is to keep making identity more decision-grade with each pass.

For our example protect surface, the first identity iteration may focus on enforced MFA, named vendor accounts, and cleanup of export roles. The second may reduce standing administrator access. The third may retire local accounts. The fourth may tighten service account governance. Each iteration makes the same transaction policies more enforceable, more explainable, and less dependent on assumption.

Identity Outcomes for the Example Protect Surface

After the first AAVI pass, we should be able to separate identity areas where functional Zero Trust is already within reach from areas that still need work. Achievable now may include enforcing MFA for protect-surface users, mapping enterprise groups to application roles, requiring named identities for routine access, inventorying non-human and AI identities that touch the protect surface, and logging sign-ins, service activity, or AI-agent activity through existing platforms. Work still ahead may include retiring local accounts, replacing shared vendor access, reducing standing privilege, governing service accounts and workload identities, cleaning up over-permissioned application registrations and AI connectors, rotating long-lived secrets, and tying authentication strength, credential assurance, or AI action scope to sensitive actions instead of only to initial login.

That distinction matters. Zero Trust progress is not binary. We do not say the Identity pillar is either “done” or “not done.” We ask which identity signals are strong enough to influence today’s trust decisions, which ones need improvement, and which ones cannot yet be trusted without compensating controls.

Cross Functions Keep Identity Honest

Before Zero Trust, the practical answer might be: the finance user logged in, belonged to the export group, and the application allowed the report download. After the first Identity AAVI pass, the answer should be more defensible: the named user authenticated with enforced MFA, the export role was intentionally assigned, risky sign-in conditions were evaluated, legacy authentication was not used, the export action was tied to the identity decision, and the evidence can be reconstructed later. That is not perfection. That is useful progress.

This is where the cross functions stop being background music and start acting like the kitchen timer on the coffee pot. Identity can tell us who is asking, but Visibility and Analytics, Automation and Orchestration, and Governance help us prove the answer, apply it consistently, and keep it from going stale. That is the difference between identity as a control and identity as an operating discipline.

Visibility and Analytics tell us whether identity decisions can be reconstructed later. If a finance user exports customer records, we should be able to see the named identity, authentication method, MFA or step-up result, role membership, session risk, device context if used by policy, the application action, and the final allow, challenge, limit, or deny decision. If the export happened but the logs only say “successful sign-in,” that is not decision-grade telemetry. That is a coffee receipt with no order details.

Automation and Orchestration make identity behavior repeatable. Joiner, mover, and leaver events should update access without a scavenger hunt through tickets. MFA exceptions should expire automatically unless renewed. Privileged elevation should activate for a defined task and duration, then fall away without someone remembering to clean it up after lunch. Service account ownership, credential rotation, and role assignment should follow a process instead of depending on the one administrator who knows where the spreadsheet lives.

Governance keeps identity from drifting back into comfortable bad habits. Governance decides who may approve access, how long exceptions can last, which roles require review, who owns non-human identities, and what evidence proves the policy is working. This is not governance as a quarterly spreadsheet ceremony with stale donuts and twenty-seven tabs. This is governance as an active participant in the trust decision, close enough to see when a “temporary” admin role is celebrating its third birthday.

For the Identity pillar, the interaction looks like this: identity provides the actor and related signals; visibility proves those signals were evaluated; automation applies identity changes, exception expirations, privileged elevation, and enforcement patterns the same way each time; governance confirms the policy still matches the business risk and forces drift back into the light. If any one of those pieces is missing, identity starts weakening. The user may be known, but the decision may not be explainable. The policy may be written, but the exception may never expire. The role may be correct today, but without governance it may quietly grow until it can do everything except brew the coffee.

A practical example helps. Suppose a vendor needs support access to the application. Identity should require a named vendor identity, not a shared account called VendorSupport that everyone pretends is a person. Visibility should record when that identity connected, what path was used, what actions were taken, and whether the session matched the policy statement. Automation should make the access time-bound and remove it when the support window closes. Governance should require an owner, business justification, review cadence, and expiration. That is Identity participating in a real Zero Trust decision instead of just handing someone a badge and hoping they behave.

MFA and legacy authentication are good examples of why the cross functions matter. Visibility shows which accounts are challenged, which methods are used, and which legacy paths are still active. Automation expires MFA exceptions, disables legacy paths in planned waves, and updates access when a role changes. Governance decides who can approve an exception, how long it can last, what compensating control is required, and what metric proves the risk is shrinking. Identity owns the signal, but the cross functions keep that signal from becoming theater.

The same pattern applies to every form of non-human identity, not just traditional service accounts. Identity should define each non-human actor, whether a service account, workload identity, managed identity, application registration, API client, automation account, bot, AI agent, AI assistant, autonomous workflow identity, model API identity, retrieval connector, certificate, secret, key, or token, with an owner, purpose, scope, credential or token strategy, expected behavior, approved tools, approved data sources, and action boundaries where applicable. Visibility should show when the identity runs, what it touches, where it runs from, which tools or data sources it used, and whether its behavior changed. Automation should rotate secrets, expire tokens, disable unused identities, limit access to the approved workflow, and alert when the identity acts outside its expected pattern. Governance should review the identity on a cadence and remove it when the business purpose disappears. Otherwise, the non-human or AI identity becomes the security equivalent of a coffee mug nobody recognizes but everyone keeps washing because it has always been there.

Before the Next Cup

Here is your homework before the next cup of coffee: choose one transaction from your protect surface and write the Zero Trust policy statement before you assess any pillar. Then run a light Identity AAVI pass against that statement. Ask who or what is making the request, how strongly that identity is verified, whether the role matches the action, whether privilege is standing or time-bound, whether the cross functions can prove, enforce, and govern the decision, and whether the decision can be explained later without a séance, a whiteboard reconstruction, or three people saying, “I think Bob set that up.”

Call to action: This week, do five small things. First, write one identity-focused Zero Trust policy statement for a real transaction. Second, identify one human identity signal, one non-human identity signal, and one AI identity signal that are already strong enough to influence the decision, plus one of each that still needs work. Third, verify whether MFA is enforced for the users and high-risk actions in that transaction, not merely enabled somewhere in the environment, and note which MFA method is required. Fourth, look for any legacy authentication path, long-lived non-human credential, or over-permissioned AI connector that could touch the protect surface and give it an owner, retirement date, rotation plan, action boundary, or compensating control. Fifth, check the cross functions: can Visibility prove the decision, can Automation keep the control from depending on memory, and can Governance keep the exception from becoming a permanent guest at the coffee table?

If the answer is still “the user logged in, so the action is allowed,” stay with Identity for another pass. Tighten one policy. Remove one exception. Assign one owner. Reduce one standing privilege. Retire one side door. Then verify the improvement with evidence, preferably before the coffee gets cold and the exception becomes folklore.

Zero Trust begins with identity, but it does not end there. Identity is the authority to ask, not the whole answer. Next time, we will bring the Device pillar into these same transaction flows and ask the next question: should this request be trusted from the device or workload being used right now? As always, I would love to hear your thoughts, questions, pushback, and real-world examples. Where does identity still act like a one-time gate in your environment? Which identity signals are strong enough to change an outcome today, and which ones still need work? Send your comments and ideas to hello@cletustaylor.com, share this post with someone trying to make Zero Trust practical instead of theoretical, and come back next time. I’ll have the coffee ready, and I promise not to make you diagram every service account before the first sip unless you bring donuts.