Parts 1 and 2 of this series covered the governance programme structure and the policies needed to operationalise it. This post covers the legal and regulatory framework that shapes those policies: the existing laws that already apply to AI systems whether organisations recognise it or not, the AI-specific legislation being enacted across multiple jurisdictions, and the voluntary standards that provide governance structure for organisations seeking to formalise their approach.

The regulatory direction globally appears to be converging around a common set of themes: risk-based classification, transparency obligations, accountability requirements, human oversight, and data governance. The specific mechanisms differ by jurisdiction, but the underlying expectations are similar enough that organisations building governance around these common themes are likely to be better positioned as regulatory requirements solidify.

This post leads with the practical questions that organisations need to answer, then provides jurisdiction-specific and standards detail in reference sections that readers can navigate to based on their needs.

The Practical Questions

The legal framework for AI can be understood through five questions that every organisation deploying AI needs to be able to answer. Each question draws from multiple bodies of law and multiple jurisdictions.

Can I use this data to train or operate an AI system?

Privacy and data protection law is relevant to this question across most jurisdictions. The specific provisions vary, but the core considerations tend to be consistent.

The lawful basis for using data in an AI system may differ from the basis under which the data was originally collected. An organisation that collected customer data for service delivery under a specific consent provision may need to establish a separate basis for using that data for model training. Most privacy frameworks generally require that each processing purpose has its own legal justification, though the specific requirements depend on the jurisdiction and the applicable legislation.

Transparency requirements are generally relevant: individuals should typically be informed that their data is or may be used in AI systems. Data minimisation principles are likely to apply: the AI system should not process more personal data than is necessary for the specific use case. Cross-border transfer rules may be triggered when training data is processed in a different jurisdiction from where it was collected. Special categories of data (biometrics, health information, racial or ethnic origin) typically carry additional restrictions that are relevant to AI systems processing images, voice, or health data.

Data protection impact assessments (DPIAs under GDPR, privacy impact assessments under the Australian Privacy Act, similar mechanisms in other frameworks) may be required or recommended for AI processing that is likely to result in high risk to individuals. These assessments should consider AI-specific risks including inference attacks, memorisation of training data, and re-identification from model outputs.

Can I deploy this AI system for this use case?

Multiple jurisdictions are converging on a risk-based classification model that determines which AI uses are permitted, which are permitted with conditions, and which are prohibited. The common tiers are: prohibited uses (systems banned outright due to unacceptable risk), high-risk uses (permitted with mandatory governance requirements including risk management, testing, documentation, human oversight, and ongoing monitoring), limited-risk uses (subject to transparency obligations such as disclosing that AI is being used), and minimal-risk uses (no specific additional requirements).

The EU AI Act provides the most detailed codification of this model. The South Korean AI Basic Act uses a similar framework with its “high-impact AI” designation. Even in jurisdictions without AI-specific legislation, existing sectoral regulation may restrict specific AI use cases: financial services regulators impose model risk management requirements, healthcare regulators govern AI-based medical devices, and employment law restricts automated hiring decisions.

Organisations should assess every proposed AI use case against the applicable risk classification, whether that comes from legislation, sectoral regulation, or the organisation’s own governance framework informed by standards such as the NIST AI RMF. The use case assessment and risk classification process described in Part 2 is the mechanism for operationalising this requirement.

What do I owe the people affected by AI decisions?

Generally speaking, three bodies of existing law are relevant to this question.

Automated decision-making provisions in privacy legislation may provide rights to individuals who are subject to decisions made by automated systems. GDPR Article 22, for example, provides rights related to solely automated decisions that produce legal or similarly significant effects, including the right to obtain human intervention, express a point of view, and contest the decision. The Australian Privacy Act includes provisions on automated decisions that significantly affect individuals’ rights or interests. Similar provisions exist in other privacy frameworks. The practical consideration is that AI systems making or materially contributing to decisions about individuals should generally be designed with notification, explanation, and human review capabilities, though the specific requirements depend on the applicable legislation.

Non-discrimination law is likely to be relevant to AI outputs in employment, credit, housing, insurance, and public services contexts across most jurisdictions. An AI system that produces discriminatory outcomes may violate existing non-discrimination law regardless of whether the discrimination was intentional or was an artefact of biased training data. In many jurisdictions, the concept of disparate impact means that the deploying organisation may bear responsibility for discriminatory outcomes even if the bias originated in a third-party model. This is a strong reason to include bias testing and fairness evaluation as part of the governance process before deployment and during operation.

Consumer protection law is generally relevant when AI is used in consumer-facing contexts. Unfair and deceptive practices provisions may cover misleading AI-generated content, undisclosed use of AI in customer interactions, and AI systems that do not perform as represented to consumers.

Who is liable when AI causes harm?

Liability for AI-related harm involves the intersection of product liability law, contractual arrangements, and the evolving regulatory framework. This is an area of active legal development, and the specific allocation of liability will depend on the jurisdiction and circumstances.

Product liability frameworks are being adapted for AI in several jurisdictions. The EU’s revised Product Liability Directive now includes software and AI systems within its scope. In common law jurisdictions, existing product liability and negligence frameworks may apply, though their application to AI systems is still being established through litigation.

Contractual liability depends on the representations made about the AI system’s capabilities and the allocation of responsibility between provider and deployer. The contractual considerations described in Part 2 (liability allocation, indemnification, warranty provisions) are an important mechanism for managing this risk. The accountability gap, where the deployer may be responsible for outcomes but the provider controls the model, creates a tension that contracts should address.

Intellectual property liability involves two dimensions: claims arising from copyrighted material in training data (actively being litigated across multiple jurisdictions, with significant cases in the US, EU, and elsewhere), and questions about the ownership of AI-generated outputs (which varies by jurisdiction and remains unsettled in most). Organisations using AI to generate content, code, or creative works should seek legal advice on their exposure and address these questions through the IP policy updates described in Part 2.

What documentation and compliance obligations do I have?

Documentation requirements are converging across jurisdictions and across the voluntary standards frameworks. The categories of required documentation are consistent even where the specific requirements vary.

Converging documentation requirements

• Technical documentation: Description of the AI system’s purpose, architecture, training data, testing methodology, known limitations, and performance metrics. Required by the EU AI Act for high-risk systems and GPAI models, by the South Korean AI Basic Act for high-impact AI, and recommended by NIST AI RMF and ISO 42001 for all AI systems proportional to risk.

• Impact assessments: Evaluation of the AI system’s potential effects on individuals’ rights, safety, and wellbeing. Required as DPIAs under GDPR for high-risk AI processing, as Fundamental Rights Impact Assessments (FRIAs) under the EU AI Act for certain high-risk systems, and as impact assessments under the South Korean AI Basic Act. Recommended by NIST AI RMF and ISO 42005 for all AI systems proportional to risk.

• Risk management records: Documentation of risk identification, assessment, mitigation, and residual risk acceptance. Required for high-risk systems under the EU AI Act and the South Korean AI Basic Act. Core to NIST AI RMF’s Manage function and ISO 42001’s management system requirements.

• Monitoring and incident records: Ongoing records of system performance, fairness metrics, drift detection, and incident management. Post-market monitoring is required under the EU AI Act. Continuous monitoring is a core element of NIST AI RMF and ISO 42001.

• Transparency disclosures: Information provided to users, affected individuals, and regulators about the AI system’s use, capabilities, and limitations. Transparency obligations exist across all major AI regulatory frameworks, with specific requirements varying by risk tier and jurisdiction.

AI-Specific Legislation Across Jurisdictions

The regulatory landscape for AI-specific legislation is developing at different speeds across jurisdictions. Before covering individual frameworks, it is worth noting the common elements that appear across all of them: risk-based classification, transparency obligations, accountability requirements, human oversight mandates for high-risk applications, and data governance standards. Organisations that build their governance around these common elements will find that adapting to jurisdiction-specific requirements is a matter of mapping their existing controls to the specific legislation rather than building from scratch for each jurisdiction.

European Union: AI Act

The EU AI Act is the most detailed AI-specific legislation enacted to date. It introduces a risk-based classification system with four tiers and assigns obligations based on the organisation’s role in the value chain.

Risk tiers

• Prohibited: AI systems banned outright. Social scoring by public authorities, real-time remote biometric identification in public spaces (with narrow law enforcement exceptions), manipulation techniques exploiting vulnerabilities, emotion recognition in workplace and educational settings, and untargeted scraping of facial images for facial recognition databases. These provisions applied from February 2025.

• High-risk: AI systems in defined sectors (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice) subject to mandatory requirements: risk management systems, data governance, technical documentation, record-keeping, transparency to users, human oversight, accuracy, robustness, and cybersecurity. Conformity assessments, registration in the EU database, post-market monitoring, and serious incident reporting are required. These provisions apply from August 2026.

• Limited risk: Transparency obligations for systems interacting with individuals (chatbots must disclose they are AI, deepfake content must be labelled). These provisions applied from August 2025.

• Minimal risk: No specific additional requirements beyond voluntary codes of practice.

Providers of general-purpose AI (GPAI) models have additional obligations including technical documentation, copyright compliance policies, and training data summaries. GPAI models classified as posing systemic risk face further requirements including adversarial testing, incident reporting, and cybersecurity measures. These provisions applied from August 2025.

Most organisations reading this post will be deployers. Deployer obligations include using high-risk systems in accordance with the provider’s instructions, ensuring human oversight, monitoring for risks in their specific deployment context, conducting Fundamental Rights Impact Assessments for certain public-sector uses, and reporting serious incidents. Penalties for non-compliance reach up to €35 million or 7% of global annual turnover.

South Korea: AI Basic Act

The AI Basic Act, enacted in January 2025 and effective from January 2026, makes South Korea the second jurisdiction after the EU to adopt comprehensive AI legislation and the first in Asia-Pacific. The Act covers both AI development operators (who build AI) and AI utilisation operators (who deploy AI products and services).

High-impact AI, defined as systems that significantly affect human life, safety, or fundamental rights in sectors including healthcare, energy, transportation, hiring, credit evaluation, and biometric analysis, carries specific obligations: operators must assess whether their system qualifies as high-impact, provide meaningful explanations of AI outputs and the criteria used, establish user protection plans, implement human oversight mechanisms, and document safety and reliability measures. Impact assessments evaluating effects on fundamental rights are encouraged. Generative AI operators must notify users that their product uses AI and label AI-generated content. Penalties are moderate compared to the EU AI Act (fines up to KRW 30 million, approximately USD 21,000), reflecting the Act’s emphasis on promoting innovation alongside governance.

The Act has extraterritorial application: foreign AI operators meeting certain user or revenue thresholds in South Korea must designate a domestic representative.

Other jurisdictions

United States. No comprehensive federal AI legislation exists. The regulatory approach is sector-specific (OCC for banking AI, FDA for healthcare AI, SEC/CFTC for financial services AI, FTC for consumer protection) combined with executive orders and the NIST AI Risk Management Framework as the de facto governance standard. State-level activity is increasing: Colorado, Illinois, and other states have enacted AI-related provisions. The regulatory environment is fragmented, which creates compliance complexity for organisations operating across multiple states.

China. Has enacted multiple sector-specific AI regulations already in effect, including the Algorithm Recommendation Management Provisions (2022), the Deep Synthesis (Deepfake) Provisions (2023), and the Interim Measures for Generative AI Services (2023). China’s approach is operational and enforcement-ready, with requirements for algorithm registration, content labelling, and user rights. Foreign organisations operating AI services in China are subject to these requirements.

Brazil. The AI regulatory framework is under legislative development. Brazil’s approach is expected to align with the OECD AI Principles and draw from the EU AI Act’s risk-based classification model.

Canada. The proposed Artificial Intelligence and Data Act (AIDA) died in January 2025 when Parliament was prorogued. The current federal government has indicated it intends to address AI governance through privacy legislation and sector-specific regulation rather than comprehensive AI-specific legislation. At provincial level, Ontario’s Bill 194 includes AI-related provisions.

Australia. No comprehensive AI-specific legislation is currently in effect. The Australian AI Ethics Principles (published by the Department of Industry, Science and Resources) provide a voluntary governance framework. The Privacy Act’s automated decision-making provisions apply to AI systems processing personal information. The government has indicated that a mandatory framework for high-risk AI may be forthcoming, but no legislation has been introduced at the time of writing.

The regulatory direction across jurisdictions is converging toward a common model: risk-based classification of AI systems, mandatory requirements for high-risk uses (transparency, human oversight, documentation, monitoring), and accountability for both developers and deployers. Organisations that build governance around these convergent elements, using the lifecycle policies and risk classification framework described in Part 2, will be positioned to adapt as jurisdiction-specific requirements solidify.

Existing Laws That May Apply to AI

AI-specific legislation is new. Many existing legal obligations are likely to apply to AI systems already. The specific applicability depends on the jurisdiction, sector, and use case, and organisations should seek legal advice on their particular circumstances.

Privacy and data protection

GDPR, the Australian Privacy Act, CCPA, Brazil’s LGPD, South Korea’s PIPA, and their equivalents across jurisdictions all apply to AI systems that process personal data. The key provisions relevant to AI include: lawful basis requirements (consent, legitimate interest, or other bases as applicable to AI-specific processing), transparency obligations (informing individuals about AI processing), data minimisation (limiting personal data in training sets to what is necessary), automated decision-making rights (notification, explanation, human review), DPIAs for high-risk processing, and cross-border transfer mechanisms for data that moves between jurisdictions during training or inference.

AI-specific risks that privacy frameworks were designed to address include inference attacks (extracting personal information from model outputs through targeted queries), memorisation (models reproducing personal data from training sets in their outputs), and re-identification (combining model outputs with other data to identify individuals from ostensibly anonymised datasets).

Non-discrimination and civil rights

Employment law, credit and lending regulation, housing law, insurance regulation, and public services frameworks generally prohibit discrimination on the basis of protected characteristics. These provisions are likely to apply to AI outputs regardless of intent. An AI hiring tool that systematically disadvantages applicants of a particular gender or ethnicity may violate non-discrimination law even if the bias was an unintended artefact of the training data. The concept of disparate impact (where a facially neutral practice produces discriminatory outcomes) is established across multiple jurisdictions and may apply to AI systems.

The practical consideration is that bias testing and fairness evaluation are prudent for AI systems operating in these contexts, and may be required under existing anti-discrimination law depending on the jurisdiction.

Consumer protection

Consumer protection frameworks are likely to be relevant when AI is used in consumer-facing contexts. Unfair and deceptive practices provisions may cover scenarios including AI-generated content presented as human-authored, undisclosed use of AI in customer service interactions, and AI systems that do not perform as advertised. As AI-generated content becomes more prevalent, consumer protection regulators in several jurisdictions are paying increasing attention to disclosure and accuracy obligations.

Product liability

Product liability frameworks are being updated in several jurisdictions to address AI. The EU’s revised Product Liability Directive now includes software and AI systems within its scope. In common law jurisdictions, existing negligence and product liability frameworks may apply to AI, though their specific application is still being established through litigation. The general direction suggests that AI systems are likely to face similar accountability expectations as other products that can cause harm, though the specific legal standards are still developing.

Intellectual property

Two IP questions are relevant to AI governance. First, the use of copyrighted material in training data. This is actively being litigated across multiple jurisdictions (major cases in the US involving New York Times v. OpenAI, Getty Images v. Stability AI, and others; EU AI Act Article 53 requires GPAI providers to implement copyright compliance policies). Organisations should assess their exposure and ensure their IP policy addresses training data rights as described in Part 2.

Second, the ownership of AI-generated outputs. This varies by jurisdiction and is unsettled in most. Some jurisdictions require human authorship for copyright protection, which may mean AI-generated outputs are not copyrightable. The practical governance action is to establish an organisational position on the use and ownership of AI-generated outputs and communicate it through the IP policy.

Standards and Frameworks

Voluntary standards and governance frameworks provide the structure for operationalising legal requirements. They translate regulatory principles into governance activities that organisations can implement.

For organisations already operating under ISO 27001 for information security, ISO 42001 provides the most natural extension for AI governance. The management system structures (policy, risk assessment, controls, monitoring, continual improvement) are consistent, and the two certifications can be managed as an integrated management system. For organisations that have adopted NIST CSF for cybersecurity governance, NIST AI RMF provides a similarly natural extension, with consistent terminology and a complementary structure.

Navigating Multiple Frameworks

The practical reality for most organisations is that they may be subject to multiple overlapping frameworks: existing privacy law in the jurisdictions where they operate, emerging AI-specific legislation (the EU AI Act if they have EU exposure, the South Korean AI Basic Act if they serve Korean markets), industry-specific regulation in their sector, and whatever voluntary standards they have adopted.

Building separate compliance programmes for each framework is unlikely to be practical or efficient. The governance programme described in Parts 1 and 2, with its risk classification, lifecycle policies, and cross-functional governance structures, can serve as a common foundation. The converging themes across jurisdictions (risk-based classification, transparency, accountability, human oversight, documentation, monitoring) map onto the lifecycle governance stages from Part 2. Jurisdiction-specific obligations can be implemented as specific activities within those stages, with legal advice on the particular requirements that apply.

Organisations that build governance around the convergent themes are likely to find that adapting to jurisdiction-specific requirements is a more manageable exercise than building from scratch for each new regulation. The legal and regulatory environment will continue to evolve, and governance programmes should be designed with that evolution in mind.

Part 4 of this series covers how these legal and policy requirements are implemented in practice during AI system development: design decisions, data governance, training, and testing.

Series Navigation

• Part 1 - Foundations

• Part 2 - Policies and Lifecycle

• Part 3 - Legal and Regulatory Framework

• Part 4 - Developing AI Systems

• Part 5 - AI in Production

• Part 6 - Deploying and Using AI

Part 1 of this series established why AI governance requires its own programme and where it integrates with existing governance frameworks. This post covers the practical output of that programme: the policies that translate principles into operational controls, the lifecycle governance mechanisms that apply at each stage of an AI system’s life, and the third-party risk management practices that govern AI systems built by others.

A common instinct when building an AI governance programme is to start with a blank page and create an entirely new policy framework. For most organisations, this is the wrong approach. It creates a parallel governance structure that operates independently from existing security, privacy, risk, and vendor management policies. The result is duplication, confusion about which policies apply in a given situation, and gaps where the AI-specific policies assume coverage that the existing policies do not provide.

The more effective approach is to work from what exists. Identify the existing policies that already apply to AI systems, update them to ensure AI-specific considerations are within scope, and create new policies only for the areas that existing frameworks genuinely do not cover. This produces a governance structure that is integrated with the organisation’s existing controls rather than layered on top of them.

Extending Existing Policies for AI

Most organisations have mature policies for data governance, information security, privacy, intellectual property, and acceptable use of technology. Each of these needs to be reviewed and, in most cases, updated to ensure that AI systems and AI infrastructure fall within their scope. The updates are about coverage, ensuring AI is explicitly included, rather than about creating separate AI-specific controls that duplicate what already exists.

Data governance

Existing data governance policies cover data classification, retention, access control, and quality standards. These controls apply to AI systems, but AI introduces additional considerations that the existing policy likely does not address.

Training data governance is the most significant gap. The rights to use data for model training may differ from the rights to use that data for its original purpose. An organisation may have collected customer data for service delivery under specific consent provisions, but using that data to train a machine learning model may require a different legal basis. The data governance policy should address whether organisational data can be used for training, what approvals are required, and how training data usage is documented.

Data quality assessment for AI purposes also extends beyond conventional data quality. Training data must be evaluated for representativeness (does it adequately represent the population the model will serve), for bias (does it contain systematic imbalances that will produce discriminatory outputs), and for provenance (can the origin and processing history of the data be traced and verified). These assessments are not covered by standard data quality frameworks, which focus on accuracy, completeness, and consistency.

The policy should also address synthetic data (how is it governed, how is its quality assured, how is its use documented), data lineage requirements for AI (tracing data from source through transformation to model input), and the handling of data used for fine-tuning and retrieval-augmented generation (RAG), which may introduce data access patterns that existing classification controls do not anticipate.

Information security

Existing security policies cover access control, encryption, logging, vulnerability management, and incident response. These controls apply to AI infrastructure in the same way they apply to any other technology asset. The update required is a scope extension, ensuring that AI infrastructure is explicitly included within existing security controls rather than inadvertently excluded.

Model weights and training data should be classified under the organisation’s data classification scheme and protected accordingly. AI serving endpoints, vector databases, agent harnesses, and MCP servers should be included in asset inventories and subject to existing vulnerability management processes. AI-specific attack vectors (prompt injection, data poisoning, model extraction, training data inference) should be incorporated into the organisation’s threat model and reflected in incident classification criteria.

The most important practical update is ensuring that AI infrastructure credentials are managed within existing secrets management practices. Industry data shows that AI service credentials are the fastest-growing category of leaked secrets, with MCP configuration files frequently containing hardcoded API keys because documentation and quickstart guides often encourage this pattern. The fix is to bring AI credentials within the scope of existing secrets management, rotation, and monitoring policies, with the same standards that apply to every other credential in the environment.

Similarly, AI-related security incidents (a compromised model serving endpoint, a data poisoning attempt, an agent operating outside its defined boundaries) should be classified and managed within the existing incident response framework, with AI-specific playbooks added to the existing runbook library rather than maintained in a separate system.

Intellectual property

Existing IP policies cover ownership, licensing, and protection of organisational intellectual property. AI introduces several questions that these policies likely do not address.

Ownership of AI-generated outputs is the first. When a model generates code, text, images, or analytical outputs, who owns them? The answer depends on the licensing terms of the model, the jurisdiction, and the nature of the output. The policy should establish the organisation’s position on ownership of AI-generated work product and require that licensing terms for models and training datasets are reviewed before deployment.

The IP implications of training data are the second. If copyrighted material is included in training data (whether through licensed datasets, web scraping, or third-party models trained on public data), the organisation’s exposure to IP claims should be assessed. Open-source model licences often include restrictions on commercial use, redistribution, or derivative works that differ from conventional software licences and may not be caught by standard software procurement review processes.

The use of AI-generated code in production software requires specific attention. If developers use code generation tools, the organisation needs a position on code review requirements for AI-generated code, attribution and licensing obligations, and liability for defects in generated code.

Privacy

Existing privacy policies cover collection, use, disclosure, and retention of personal information. AI extends these in several specific areas.

Automated decision-making provisions in privacy legislation (GDPR Article 22, the Australian Privacy Act’s provisions on automated decisions that significantly affect individuals) require that organisations identify where AI systems make or contribute to decisions about individuals, provide notification that automated processing is occurring, and offer rights to human review and explanation of automated decisions. The privacy policy should require an assessment of automated decision-making provisions for any AI system that processes personal information.

The use of personal data in training and fine-tuning may require a different lawful basis than the one under which the data was originally collected. Data minimisation in AI contexts means ensuring that models are not exposed to more personal data than is necessary for the use case, which may require filtering, anonymisation, or synthetic data substitution before data enters a training pipeline.

Privacy impact assessments for AI systems should evaluate AI-specific risks including inference attacks (can the model reveal information about individuals in its training data through targeted queries), memorisation (does the model reproduce personal data from its training set in its outputs), and re-identification (can anonymised data be re-identified through model outputs or through combination with other data sources).

Acceptable use

Most organisations already have an acceptable use policy (AUP) that covers how employees use technology: internet access, email, social media, cloud storage, BYOD. AI tools are a new category of technology that the existing AUP needs to cover, following the same principle applied to the other four policy areas. When social media became prevalent, organisations updated their existing AUPs to address it. When cloud storage services emerged, the AUP was extended again. AI tools warrant the same treatment.

The AI-specific additions to the existing AUP should address the following areas.

• Approved tools and services: Which AI tools and services employees are permitted to use for work purposes. This should include both dedicated AI applications (ChatGPT, Claude, Copilot) and AI features embedded within existing SaaS platforms (Salesforce Einstein, Notion AI, Gmail’s Smart Compose). Shadow AI, where employees use unapproved AI tools for work tasks, is a growing governance gap. According to Gallup, 46% of US employees used AI at least a few times a year by Q4 2025, but only 22% said their organisation had communicated a clear plan or strategy for AI use.

• Data classification restrictions: What data can be provided to AI systems, based on the organisation’s data classification scheme. Confidential and restricted data should generally not be entered into external AI services unless the service meets specific contractual and security requirements. The policy should be specific about what “confidential data” includes in this context: customer personal information, financial data, source code, internal strategy documents, employee data.

• Output review and validation: How AI-generated outputs should be reviewed before use. AI outputs should be treated as drafts that require human review, especially for content that will be published externally, used in decision-making about individuals, or incorporated into production systems. The policy should specify the level of review required based on the risk level of the use case.

• Disclosure requirements: When the use of AI must be disclosed. This may include disclosure to customers (if AI is used in customer-facing interactions), to partners (if AI-generated content is shared externally), and to regulators (if AI is used in regulated processes). Disclosure requirements vary by jurisdiction and sector, and the policy should align with the organisation’s legal obligations.

• Prohibited uses: Use cases that the organisation has determined are too high-risk or ethically inappropriate. These should be specific and tied to the organisation’s risk classification framework. Examples might include using AI for autonomous hiring decisions without human review, using AI to generate synthetic media depicting real individuals without consent, or using AI to make lending decisions that cannot be explained to the applicant.

For most organisations, these additions fit naturally within the existing AUP’s structure. If the volume of AI-specific guidance becomes substantial enough to make the existing AUP unwieldy, a standalone AI acceptable use document can be maintained as a referenced appendix. That is an organisational decision about document management, not a governance principle.

AI Lifecycle Policies

The policies described above are extensions of existing frameworks. The following policies are specific to the AI lifecycle and have no direct equivalent in conventional governance. They govern the stages of an AI system’s life, from initial use case assessment through deployment, monitoring, and eventual decommissioning.

Use case assessment and approval

Before an AI system is developed or procured, the proposed use case should go through an assessment that determines the level of governance rigour that will apply throughout its lifecycle. This assessment evaluates the business justification, the intended users and affected individuals, the types of data involved, the potential for harm if the system fails or produces biased outputs, and whether the use case falls within the organisation’s defined boundaries for acceptable AI use.

The assessment should produce a risk classification that determines what happens next. Low-risk use cases (internal productivity tools, summarisation of non-sensitive documents) may proceed with lightweight governance: a documented assessment, compliance with the acceptable use policy, and standard security controls. High-risk use cases (systems that make or influence decisions about individuals’ access to services, employment, credit, insurance, or safety) should require governance committee or executive-level approval, a formal impact assessment, specific testing requirements for bias and fairness, human oversight design, and ongoing monitoring obligations.

The EU AI Act’s risk classification framework (prohibited, high-risk, limited, minimal) provides one reference model for this tiering. Organisations may define their own categories based on their risk appetite, regulatory context, and sector-specific obligations, but the principle of proportional governance, applying more rigour where the potential for harm is greater, should be consistent.

Ethics by design

Fairness, transparency, and human oversight are more effectively addressed during the design phase than evaluated after the system is built. A policy requiring ethics-by-design ensures that these considerations are part of the design specification rather than an afterthought discovered during a pre-deployment review.

The policy should require stakeholder identification (who is affected by this system and how their interests might be harmed), fairness criteria selection (which definition of fairness applies to this use case, acknowledging that different definitions can conflict), explainability requirements (what level of explanation is required for this system’s outputs, given its risk classification and regulatory obligations), and human oversight design (what mechanisms exist for a human to review, override, or shut down the system, and under what conditions those mechanisms should be activated).

For high-risk systems, the ethics-by-design assessment should be a documented deliverable that is reviewed by the governance committee and retained as part of the system’s governance record.

Development and testing standards

Policies governing how AI systems are built and validated should address documentation requirements at each development stage, testing requirements proportional to risk classification, peer review requirements for model development, and the criteria that must be met before a system can proceed from development to deployment.

Testing requirements are where the risk classification has the most practical impact. A minimal-risk system (a content recommendation engine for internal knowledge articles) may require standard functional testing and basic performance validation. A high-risk system (a credit scoring model) should require bias testing across protected characteristics, adversarial testing, interpretability analysis, and validation against holdout datasets that represent the population the model will serve. Part 4 of this series covers these testing disciplines in detail.

The relationship between AI testing standards and the organisation’s existing software development lifecycle (SDLC) and quality assurance (QA) processes should be explicitly defined. AI testing extends conventional software testing but does not replace it. Standard code review, unit testing, integration testing, and security testing all still apply. The additional AI-specific testing (bias, fairness, interpretability, adversarial robustness) sits alongside them.

Deployment and monitoring

Policies governing how AI systems are released into production and how they are monitored once operational cover three areas: readiness, documentation, and ongoing surveillance.

Production readiness criteria define the conditions that must be met before deployment: successful completion of all required testing, approval from the governance committee (for high-risk systems), completion of all documentation requirements, establishment of monitoring infrastructure, and confirmation that incident response procedures are in place. Model cards or system documentation should accompany every deployed system, recording the model’s purpose, training data description, known limitations, performance metrics, and the conditions under which it should not be used.

Continuous monitoring requirements should specify what metrics are tracked (performance, fairness, drift, safety), how frequently they are evaluated, what thresholds trigger intervention, and who is responsible for responding. Model drift (where the model’s performance degrades over time because the data distribution changes) is a risk that has no direct parallel in conventional software and requires dedicated monitoring. Part 5 of this series covers monitoring and production governance in detail.

Incident management

AI-related incidents should be managed within the organisation’s existing incident response framework, with AI-specific classification criteria and investigation procedures added to the existing process. Creating a separate AI incident management process would fragment operational response and create confusion about escalation paths.

What the existing framework needs to accommodate is the range of events that constitute an AI incident. These include biased outputs affecting a class of users, model failure causing operational disruption, data breach involving training data, adversarial attack on a deployed model (prompt injection, data poisoning, model extraction), an autonomous agent taking actions outside its defined boundaries, and regulatory non-compliance discovered in a deployed system.

Investigation procedures for AI incidents may differ from conventional IT incidents. Root cause analysis may require examining training data quality, model architecture decisions, testing gaps, or drift in input data distributions. The investigation may need to involve data scientists and ML engineers alongside the security and operations teams that typically lead incident response. The policy should define when these specialists are engaged and how their findings are documented.

Reporting obligations may also differ. AI-specific legislation may require notification to regulators when certain types of AI incidents occur, particularly for high-risk systems. The incident management policy should reference these obligations and define the notification workflow.

Documentation and reporting

Documentation serves both internal governance needs (accountability, institutional memory, audit readiness) and external obligations (regulatory compliance, transparency to affected individuals, third-party audit). The documentation policy should specify what documentation is required at each lifecycle stage and who is responsible for creating and maintaining it.

Documentation requirements by lifecycle stage

• Design and approval: Use case assessment, risk classification, ethics-by-design assessment, impact assessment (for high-risk systems), governance committee approval records.

• Development: Training data description and provenance, model architecture documentation, testing plans and results (including bias and fairness testing), known limitations, peer review records.

• Deployment: Model card or system documentation, production readiness approval, monitoring configuration, incident response procedures, rollback plan.

• Operations: Monitoring reports, performance and fairness metrics over time, incident records, retraining records, drift analysis results, access and change logs.

• Governance: Policy exception records, risk acceptance documentation, audit findings and remediation records, regulatory correspondence.

Documentation is one of the areas where governance programmes most frequently fail in practice. The policies are written, the templates are created, but the documentation is not completed or maintained because the people responsible for creating it (engineers, data scientists) view it as overhead rather than as part of the work. The governance programme needs to make documentation a required deliverable with the same enforcement as code review or security testing, built into the workflow rather than appended to it.

Third-Party AI Risk Management

For most organisations, the majority of their AI usage involves systems and services built by others: commercial LLM APIs, AI features embedded in SaaS platforms, pre-trained models from open-source repositories, and AI-powered tools used by employees. Third-party AI risk management is therefore the governance activity with the broadest day-to-day applicability.

The organisation deploying a third-party AI system is typically accountable for the outcomes that system produces in its environment, regardless of who built the model. This accountability gap, where the deployer bears the risk but the provider controls the system, is the central challenge of third-party AI governance.

Assessment during procurement

The procurement assessment for a third-party AI system extends the organisation’s existing vendor risk management process with AI-specific questions. The assessment should cover what data was used to train the model (and whether that data creates IP or bias risk), what testing the provider has performed for bias, safety, and security, what documentation is available (model cards, system cards, technical reports, known limitations), how the provider manages incidents and communicates them to customers, what data handling practices apply to inputs and outputs (whether customer data is used for training, whether it is retained after processing, and where it is processed geographically), and what the provider’s approach is to regulatory compliance (particularly under the EU AI Act, where providers of general-purpose AI models have specific obligations).

For AI features embedded within existing SaaS platforms, the assessment may be more targeted: what data does the AI feature access, can the feature be disabled if it does not meet governance requirements, does the vendor’s data processing agreement cover AI-specific processing, and what controls exist to prevent the AI feature from accessing data outside its intended scope.

Contractual considerations

AI-specific terms should be included in vendor contracts alongside standard security and data protection provisions. These include data handling commitments (no training on customer data without explicit consent, data residency requirements, retention and deletion policies for inference inputs and outputs), liability allocation for harm caused by AI outputs (who bears responsibility when the model produces biased, inaccurate, or harmful results), IP indemnification (protection against claims arising from the model’s training data), transparency obligations (notification of material model changes, disclosure of known limitations, communication of policy changes that affect data handling), audit rights (the ability to assess the provider’s AI governance practices, either directly or through third-party audit reports), incident notification (timely communication of AI-related incidents that may affect the organisation’s data or operations), and termination provisions (data portability, model access on contract termination, transition support).

Ongoing monitoring

The governance of third-party AI does not end at procurement. The organisation should periodically reassess the provider’s governance practices (annually at minimum, or when material changes are announced), monitor the performance and outputs of third-party AI systems within its own environment (using the same monitoring framework that applies to internally developed systems), track provider communications about model changes, updates, and incidents, and maintain the ability to switch providers or bring capabilities in-house if the provider’s governance practices deteriorate or the provider’s terms change in ways that are incompatible with the organisation’s requirements.

Supply chain risk

The AI supply chain extends beyond the model provider. It includes the data providers whose datasets were used for training, the cloud infrastructure providers that host the model, the tooling providers (MCP servers, agent frameworks, vector databases, embedding services) that form part of the delivery chain, and any intermediaries or resellers in the distribution path. Each layer introduces potential governance gaps.

A model may be developed by one organisation, fine-tuned by another, hosted by a third, and accessed through a fourth’s API. At each layer, data handling practices, security controls, and governance standards may differ. The organisation deploying the system needs visibility into the material components of the supply chain and assurance that governance practices at each layer meet its requirements. This does not require auditing every component in depth, but it does require identifying the components that materially affect the security, privacy, or fairness of the system and assessing their governance posture.

Industry data shows that AI service secrets are the fastest-growing category of leaked credentials, with 81.5% year-over-year growth. Configuration files for AI infrastructure tools frequently contain hardcoded API keys, because quickstart guides and documentation often encourage this pattern. This is a supply chain governance issue as much as a security issue: the organisation’s exposure is determined by the credential hygiene practices of every component in the AI delivery chain.

Connecting Policies to the Governance Programme

Policies are effective only if they are connected to the organisational structures, roles, and responsibilities established in the governance programme. A use case assessment policy is useful only if someone is responsible for performing the assessment, competent to perform it, and held accountable for the quality of the result. A testing policy that requires bias evaluation is useful only if the team performing the testing has the skills, tools, and time to conduct it meaningfully. A documentation policy is useful only if documentation is treated as a required deliverable with enforcement equivalent to code review or security sign-off.

The gap between written policies and operational practice is where governance programmes most commonly fail. Policies are adopted, templates are created, and governance committees are formed. The policies sit in a document management system. The templates are completed as a compliance exercise rather than as a genuine assessment. The governance committee meets quarterly and reviews dashboards that show process compliance (how many assessments were completed) rather than outcome quality (how many AI systems are operating within their defined risk parameters).

Closing that gap requires treating governance as an operational practice with the same operational discipline applied to security operations or software delivery. Policies need owners. Assessments need quality review. Documentation needs validation. Monitoring needs response.

The governance programme described in Part 1 provides the structure. The policies described in this post provide the content. The next post covers the legal and regulatory framework that shapes many of these policy requirements, including the EU AI Act’s risk classification, existing privacy and non-discrimination law as applied to AI, and the industry standards that provide additional governance structure.

Series Navigation

• Part 1 - Foundations

• Part 2 - Policies and Lifecycle

• Part 3 - Legal and Regulatory Framework

• Part 4 - Developing AI Systems

• Part 5 - AI in Production

• Part 6 - Deploying and Using AI

Every large organisation has governance frameworks for information security. Most have frameworks for data privacy, for risk management, for change control, for vendor management. These frameworks are mature, well-understood, and auditable. The question that most organisations are now confronting is whether AI can be governed within these existing structures or whether it requires something additional.

The answer is that it requires something additional. AI systems have characteristics that existing governance frameworks were not designed to address. The opacity of a neural network’s decision-making process is different in kind from the opacity of a misconfigured access control list. The potential for a language model to generate discriminatory content at scale is different from the potential for a database query to return biased results. The speed at which an autonomous agent can take consequential actions across connected systems is different from the speed at which a human operator can make mistakes.

This does not mean existing frameworks are irrelevant. ISO 27001 still governs information security controls. Privacy legislation still governs personal data processing. Risk management frameworks still apply. AI governance sits alongside these, extending them where AI introduces new considerations and adding new controls where existing frameworks have no coverage. The goal is integration, ensuring that AI governance connects to what already exists rather than creating a parallel structure that operates in isolation.

What Makes AI Different from a Governance Perspective

Software systems have been governed for decades. What is it about AI that warrants a distinct governance approach? The answer lies in a set of characteristics that, while individually present in other systems, combine in AI to create governance challenges that existing frameworks do not adequately cover.

Characteristics that require dedicated governance

• Opacity: Many AI models, particularly deep learning systems, produce outputs through processes that cannot be fully explained or audited at the individual decision level. A traditional software system can be traced through its code path. A neural network with billions of parameters cannot be traced in the same way. This creates challenges for accountability, auditability, and the ability to explain decisions to affected individuals, all of which are requirements under existing regulatory frameworks that assume explainability is technically achievable.

• Probabilistic outputs: Traditional software is deterministic: the same input produces the same output. AI systems are probabilistic: the same input may produce different outputs depending on model state, temperature settings, and stochastic processes within the inference pipeline. This means testing and validation cannot rely on the deterministic assumptions that underpin conventional software quality assurance. A system that passes testing today may produce different results tomorrow on the same inputs.

• Autonomy and agency: Agentic AI systems can plan, select tools, and execute actions across connected infrastructure with minimal human intervention. A traditional automated system follows a predefined script. An agentic system decides what to do based on its interpretation of a goal. This introduces governance questions about delegation of authority, accountability for autonomous decisions, and the boundaries within which an agent should be allowed to operate.

• Data dependency: AI system behaviour is determined as much by training data as by code. A model trained on biased data will produce biased outputs regardless of how well the surrounding code is written. This means data governance, data quality, data provenance, and the rights to use specific data for training are governance concerns that directly affect the safety and fairness of the system’s outputs. Traditional software governance focuses on code quality and configuration; AI governance must extend to data quality and lineage.

• Speed and scale of harm: An AI system making decisions at machine speed across millions of transactions can cause harm at a scale and velocity that manual processes cannot. A biased hiring algorithm that screens 10,000 applicants before the bias is detected causes more harm than a biased human recruiter who screens 50. A language model that generates misinformation can produce it faster than any human effort to correct it. The speed at which AI operates means that governance controls must be designed to detect and respond to problems in near real time.

• Emergent behaviour: Large AI systems can exhibit capabilities and behaviours that were not explicitly designed or anticipated by their developers. A model trained for one task may develop the ability to perform related tasks that were not part of its training objective. This makes comprehensive pre-deployment testing more difficult, because the full range of the system’s capabilities may not be known at the time of deployment.

Each of these characteristics, taken individually, might be addressable within an existing governance framework. Taken together, they create a governance challenge that requires its own structure, its own policies, its own risk assessment methodology, and its own accountability model. An organisation that attempts to govern AI solely through its existing information security and privacy programmes will find gaps: the bias and fairness questions that information security does not address, the explainability requirements that privacy impact assessments are not designed to evaluate, the autonomous decision-making that change management processes do not cover.

Where AI Governance Sits in the Enterprise

AI governance does not replace existing governance structures. It integrates with them. Understanding where it overlaps with and where it extends existing frameworks is essential for building a programme that is effective without being redundant.

Relationship to information security governance

Information security governance (ISO 27001, NIST CSF, SOC 2) covers the confidentiality, integrity, and availability of information assets. AI systems are information assets, and the security controls that protect them (access control, encryption, logging, incident response) are governed by existing security frameworks. What security governance does not cover is the safety and fairness of AI system outputs, the governance of training data quality and provenance, the explainability of model decisions, or the ethical implications of deploying autonomous systems. AI governance extends security governance into these areas.

Relationship to data privacy governance

Privacy legislation (GDPR, the Australian Privacy Act, CCPA) governs how personal data is collected, processed, and shared. AI systems that process personal data are subject to these requirements. Where privacy governance and AI governance overlap most directly is in automated decision-making provisions: GDPR Article 22 provides rights related to solely automated decisions with legal or significant effects, and the Australian Privacy Act includes provisions on automated decisions that significantly affect individuals. AI governance extends privacy governance by addressing the broader question of how AI decisions are made, whether those decisions are fair across different groups, and how individuals can contest or understand AI-driven outcomes.

Relationship to risk management

Enterprise risk management frameworks cover operational, financial, strategic, and compliance risk. AI introduces risk categories that these frameworks need to accommodate: algorithmic bias risk, model drift risk, data quality risk, supply chain risk from third-party models, reputational risk from AI-generated content, and the legal liability risks that arise from autonomous systems making decisions that cause harm. AI governance provides the domain-specific risk assessment methodology (impact assessments, risk classification, harm evaluation) that feeds into the broader enterprise risk register.

Relationship to vendor and third-party risk management

Most organisations deploying AI are using models and services built by third parties. The governance of these third-party relationships falls partly within existing vendor risk management frameworks (security assessments, contractual obligations, SLA monitoring) and partly within AI-specific governance (evaluating model behaviour, understanding training data practices, assessing bias in vendor-supplied models, ensuring the vendor’s AI governance programme meets the organisation’s requirements). The third-party dimension is particularly important because the organisation deploying the AI system is typically accountable for its outcomes, regardless of whether the underlying model was built in-house or procured from a vendor.

According to the IAPP’s 2025 AI Governance Profession Report, 77% of organisations are actively developing AI governance programmes, with 47% ranking AI governance among their top five strategic priorities. The regulatory pressure is getting real: the EU AI Act’s high-risk AI system requirements take full effect in August 2026, with penalties up to €35 million or 7% of global annual turnover for non-compliance.

The Risk Taxonomy

AI governance requires a clear understanding of the types of risks and harms that AI systems can cause. These risks operate at multiple levels: harms to individuals, harms to the organisation, and harms to society. A governance programme that focuses only on compliance risk to the organisation misses the individual and societal harms that increasingly drive regulatory action and reputational consequences.

Harms to individuals

AI systems can cause direct harm to individuals through biased or discriminatory outputs (a hiring algorithm that systematically disadvantages certain demographic groups), through privacy violations (a model that memorises and reproduces personal data from its training set), through safety failures (an autonomous vehicle that misclassifies a pedestrian), and through loss of autonomy (decisions made by opaque systems that individuals cannot understand, contest, or override). These harms are the primary focus of AI-specific legislation such as the EU AI Act, which classifies AI systems by risk level based partly on the potential severity of harm to individuals.

Harms to the organisation

AI systems create organisational risk through legal liability (discrimination claims, product liability, contractual breaches), reputational damage (public incidents involving biased or harmful AI outputs), operational failures (model drift causing degraded performance, AI systems making incorrect decisions at scale), intellectual property exposure (training data that includes copyrighted material, model outputs that infringe third-party IP), and regulatory non-compliance (failure to meet the requirements of AI-specific legislation). These risks are more familiar to enterprise governance professionals and map more naturally to existing risk registers.

Harms to society

At the broadest level, AI systems can cause societal harm through the amplification of misinformation, the concentration of power in entities that control large-scale AI systems, environmental impact from the computational resources required for training and inference, the erosion of trust in institutions that deploy opaque AI decision-making, and the potential for AI to be used for surveillance, manipulation, or control. These societal risks are harder to govern at the individual organisation level but are increasingly reflected in regulatory frameworks and public expectations.

A governance programme that is aware of all three levels of harm is better positioned to identify risks early, design appropriate controls, and respond effectively when incidents occur. The risk assessment methodology should evaluate proposed AI use cases against all three levels, even where the organisation’s primary concern is its own liability.

The Principles of Responsible AI

Across regulatory frameworks, industry standards, and organisational AI ethics statements, a consistent set of principles has emerged. These principles are not prescriptive controls. They are the values that inform how controls are designed, how trade-offs are evaluated, and how the organisation communicates its approach to AI governance to stakeholders, regulators, and the public.

Common principles across frameworks

• Fairness: AI systems should treat individuals and groups equitably and should not produce outcomes that discriminate on the basis of protected characteristics. Fairness in AI is technically complex because it requires defining what “fair” means in a specific context (equal outcomes, equal opportunity, calibrated predictions), and because different definitions of fairness can conflict with each other. The governance programme needs to establish which fairness criteria apply to each use case and how compliance with those criteria will be measured and monitored.

• Safety and reliability: AI systems should function as intended, should be robust against adversarial inputs and unexpected conditions, and should not cause physical, financial, or psychological harm. Safety requirements vary by context: a content recommendation system has different safety requirements from a medical diagnostic system. The governance programme should include risk classification that determines the level of testing, validation, and monitoring required based on the potential consequences of system failure.

• Privacy and security: AI systems should protect the privacy of individuals whose data is used in training, inference, or system outputs. Security controls should protect the AI system against adversarial attacks, data poisoning, model theft, and prompt injection. This principle connects AI governance directly to existing information security and privacy governance frameworks.

• Transparency and explainability: Organisations should be transparent about when and how AI is used, and AI systems should be able to provide explanations of their outputs that are meaningful to the people affected by them. The level of explainability required depends on the context: a music recommendation system may require minimal explanation, while an automated credit decision requires a detailed explanation of the factors that contributed to the outcome. Regulatory frameworks increasingly mandate both transparency (disclosing that AI is being used) and explainability (providing reasons for individual decisions).

• Accountability: There should be clear accountability for the outcomes produced by AI systems. This means identifiable individuals or roles are responsible for the design, deployment, and ongoing operation of each AI system. It also means that mechanisms exist for individuals affected by AI decisions to seek recourse, and that the organisation can demonstrate to regulators how decisions were made and who was responsible for them.

• Human-centricity: AI systems should be designed to augment human capabilities and serve human needs, with human oversight appropriate to the risk level of the system. For high-risk applications, this means maintaining the ability for a human to review, override, or shut down an AI system. The EU AI Act codifies this as a requirement for high-risk AI systems, mandating that such systems are designed to allow effective human oversight.

These principles are broadly consistent across the OECD AI Principles, the Australian AI Ethics Principles, the NIST AI Risk Management Framework, and the EU AI Act. The specific terminology varies, but the underlying values converge. A governance programme built on these principles can adapt to different regulatory requirements as they evolve because the principles provide a stable foundation even as specific regulatory obligations change.

Establishing the Governance Programme

Principles and risk taxonomies provide the conceptual foundation. The governance programme itself requires organisational structure, defined roles, cross-functional collaboration, and an approach that is calibrated to the organisation’s size, maturity, and risk profile.

Roles and responsibilities

AI governance cannot sit within a single function. The decisions involved span technology (model selection, architecture, security), legal (regulatory compliance, liability, IP), ethics (fairness, bias, societal impact), business (use case selection, cost-benefit, customer impact), and risk (enterprise risk integration, audit, reporting). A governance programme that is owned exclusively by the technology function will underweight legal and ethical considerations. One that is owned exclusively by legal will underweight technical feasibility and operational reality.

The typical organisational model involves an AI governance committee or council with representation from each relevant function, supported by subject matter specialists who perform the detailed assessment work. The committee provides strategic direction, sets policy, reviews high-risk use cases, and reports to executive leadership and the board. The specialists perform impact assessments, evaluate model behaviour, monitor deployed systems, and manage incidents.

Clear ownership is essential. For each AI system, there should be an identifiable owner who is accountable for its governance compliance, its ongoing performance, and the resolution of any issues that arise. This ownership should be documented and should persist through the system’s lifecycle, including after the individuals who originally deployed the system have moved to other roles.

Cross-functional collaboration

The cross-functional nature of AI governance is one of its defining characteristics. A decision about whether to deploy a customer-facing chatbot involves technology (can it be built safely), legal (does it comply with consumer protection and privacy law), marketing (how will customers perceive it), risk (what happens if it produces harmful outputs), and operations (who monitors it, who responds to incidents). No single function has the expertise to evaluate all of these dimensions.

Effective cross-functional collaboration requires shared terminology (all stakeholders need to understand what “bias” means in this context, what “explainability” means, what “high-risk” means), shared processes (a common impact assessment template, a common risk classification framework), and shared tools (a common registry of AI systems, a common incident management process). Without these, cross-functional governance becomes a series of disconnected reviews by functions that are each applying their own criteria and reaching their own conclusions.

Training and awareness

AI governance is effective only if the people building, deploying, and using AI systems understand what is expected of them. This requires training at multiple levels: awareness training for all employees who interact with AI systems (what AI is, how it works at a basic level, what the organisation’s AI policies require), technical training for engineers and data scientists (bias detection methods, security testing for AI systems, documentation requirements), and governance training for managers and executives (risk classification, regulatory obligations, accountability structures).

The training programme should be ongoing rather than a one-time exercise. AI capabilities, regulatory requirements, and organisational policies all evolve. A training programme that was current 12 months ago may not reflect the current state of the technology or the regulatory environment.

Scaling governance to the organisation

The governance approach should be proportional to the organisation’s AI maturity, size, and risk exposure. A 50-person company using a third-party chatbot for customer support requires a different governance structure from a 50,000-person financial institution building proprietary trading models. The principles remain the same, but the formality, resourcing, and depth of the governance programme should scale appropriately.

For organisations early in their AI adoption, the governance programme may be a set of policies, an impact assessment process for new AI use cases, and a small cross-functional review group. For organisations with mature AI programmes and significant regulatory exposure, the governance programme may include dedicated AI risk analysts, automated monitoring of deployed models, regular audit cycles, and board-level reporting on AI risk metrics.

The key distinction from a governance perspective is the role the organisation plays in the AI value chain. An organisation that develops its own AI models carries different responsibilities from one that deploys models built by third parties. A developer must govern the training data, the model architecture, the testing regime, and the documentation. A deployer must evaluate the vendor’s governance practices, perform its own impact assessment for the specific use case, govern the deployment configuration and monitoring, and maintain accountability for the outcomes the system produces. Many organisations occupy both roles simultaneously, developing some AI capabilities internally while deploying third-party models for others. The governance programme needs to account for both.

What This Series Covers

This post has established the foundations: why AI governance needs its own programme, where it sits relative to existing governance frameworks, the risk taxonomy, the common principles, and the organisational structure needed to make governance effective. The remaining five posts in this series cover the lifecycle of AI governance in practice.

• Part 2 covers the policies and procedures that apply across the AI lifecycle, including how to extend existing organisational policies for AI and how to manage third-party AI risk.

• Part 3 covers the legal and regulatory framework: existing laws (privacy, IP, non-discrimination, consumer protection, product liability) that apply to AI, AI-specific legislation (the EU AI Act and emerging equivalents), and the industry standards and frameworks (OECD AI Principles, NIST AI RMF, ISO 42001) that provide the governance structure.

• Part 4 covers governing AI development: design, data governance, training, and testing.

• Part 5 covers governing AI in production: release readiness, continuous monitoring, incident management, and transparency obligations.

• Part 6 covers governing AI deployment and use from the deployer’s perspective: model selection, impact assessment, vendor evaluation, and the ongoing governance of deployed systems.

Together, these six posts provide a reference for building an AI governance programme that is grounded in established principles, aligned with the regulatory direction, and practical enough to implement within the constraints of a real organisation.

The deployment of autonomous AI agents in the enterprise has accelerated beyond what most governance and security teams anticipated. Gartner projects that 40% of enterprise applications will incorporate task-specific agents by the end of 2026, up from less than 5% in 2025. The Model Context Protocol (MCP) has crossed 97 million SDK downloads and 10,000 enterprise server implementations. The Agent-to-Agent (A2A) protocol has more than 150 organisations in production use within its first year. The infrastructure for a multi-agent enterprise is being built steadily.

The governance, identity, and security infrastructure has not kept pace. According to the Gravitee State of AI Agent Security 2026 Report, only 14.4% of organisations report their AI agents go live with full security and IT approval. NIST launched the AI Agent Standards Initiative in February 2026, the first federal programme dedicated to agent interoperability and security, and the comment periods have only recently closed. The first normative output, the AI Agent Interoperability Profile, is targeted for Q4 2026. The standards are being written while the systems are being deployed.

This post provides an early architectural map of the agentic AI enterprise: what is emerging, what is settling, and what remains unresolved. Some of these patterns will consolidate into lasting standards. Others may be superseded as the field matures. The post is written with that uncertainty in mind, focusing on the structural patterns and governance principles that are likely to persist regardless of which specific protocols or platforms prevail.

What Is Agentic AI?

An AI agent is a software system that receives a goal, reasons about how to achieve it, selects and executes actions, evaluates the results, and iterates until the goal is met or the system determines it cannot proceed. The defining characteristic is autonomy: the agent decides what to do based on its interpretation of the goal, rather than following a predefined script. A traditional automated workflow executes a fixed sequence of steps. An agent determines the steps at runtime.

Several properties distinguish agentic systems from conventional AI and automation. Goal-orientation means the agent works toward an outcome rather than responding to a single prompt. Planning means the agent decomposes complex goals into subtasks and determines the order of execution. Tool use means the agent interacts with external systems (APIs, databases, file systems, communication platforms) to take actions in the world. Memory means the agent retains context across interactions, within a session or across sessions, and uses that context to inform future decisions. Delegation means the agent can invoke other agents or services to handle subtasks it cannot or should not perform itself.

Core components

An agentic system is composed of several building blocks, each of which carries its own governance and security considerations.

Building blocks of an agentic system

• Foundation model: The large language model (or other AI model) that provides the agent’s reasoning, language understanding, and generation capabilities. The foundation model is the cognitive core: it interprets goals, generates plans, constructs tool calls, and evaluates results. It may be a commercial API (GPT, Claude, Gemini), an open-source model (Llama, Mistral), or a domain-specific model fine-tuned for a particular industry. The choice of foundation model affects the agent’s capability, cost, explainability, and the organisation’s data handling obligations.

• System prompt and instructions: The instructions that define the agent’s role, constraints, personality, and operating boundaries. The system prompt shapes what the agent will and will not do. It is the primary mechanism for constraining agent behaviour, and its design is considered a governance activity. A poorly scoped system prompt can allow the agent to operate outside its intended boundaries.

• Tool definitions: Structured descriptions of the external capabilities available to the agent: what each tool does, what parameters it accepts, and what it returns. Tool definitions are provided to the agent as part of its context and determine what actions the agent can take. In the MCP ecosystem, tool definitions are served by MCP servers. The set of tools available to an agent defines its effective capability and its potential attack surface.

• Memory and context: The mechanisms by which the agent retains and retrieves information across interactions. Short-term memory (the conversation or task context within a session) is typically managed through the model’s context window. Long-term memory (information persisted across sessions) may be stored in vector databases, knowledge graphs, or conventional databases. Retrieval-Augmented Generation (RAG) pipelines allow the agent to search external knowledge bases at runtime, grounding its responses in organisational data. Memory and retrieval systems determine what information the agent can access, which has direct implications for data governance and access control.

• Orchestration layer: This is the logic that manages the agent’s execution loop: receiving a goal, invoking the model to generate a plan, executing tool calls, evaluating results, and deciding whether to continue, retry, escalate, or terminate. In single-agent systems, the orchestration layer is typically part of the agent framework (LangChain, LangGraph, CrewAI, Autogen, or custom implementations). In multi-agent systems, the orchestration layer also manages which agents are involved, how tasks are delegated, and how results are aggregated.

• Guardrails and safety layer: The controls that regulate agent behaviour during execution: input validation (filtering harmful or manipulative inputs before they reach the model), output validation (checking that the agent’s planned actions fall within approved boundaries before execution), content filtering (blocking harmful, biased, or inappropriate outputs), rate limiting (preventing runaway execution), and human-in-the-loop gates (requiring approval for high-consequence actions). The guardrails layer is the enforcement layer for governance policies at runtime.

The agent harness

The components described above do not operate independently. They are assembled into an agent harness. It refers to the complete runtime environment that wraps the foundation model and connects it to tools, data, memory, guardrails, and the orchestration logic that drives the agent’s execution loop. When an agent is deployed to production, the harness is what is deployed: the model, its system prompt, the tool definitions it can access, the memory stores it reads from and writes to, the guardrails that regulate its behaviour, and the orchestration logic that determines how it plans, executes, and evaluates.

From a security and governance perspective, the harness is the attack surface. A compromised system prompt, a poisoned tool definition, a manipulated memory store, or a misconfigured guardrail all sit within the harness. Auditing an agent means auditing the harness. This involves reviewing the prompt for scope creep, the tool definitions for unauthorised capabilities, the retrieval pipeline for data access violations, the guardrails for bypass conditions, and the orchestration logic for escalation and termination paths. The harness should be treated with the same configuration management rigour applied to any other production deployment and must be version-controlled, change-managed, and subject to security review before deployment and after any modification.

Integrations and connectors

An agent’s utility comes from its ability to interact with external systems. The integration layer connects the agent to the tools, data sources, and services it needs to accomplish its goals.

• Tool connectors provide the agent with the ability to call external APIs: reading from and writing to databases, querying search engines, sending emails, creating tickets, modifying records in CRM and ERP systems, executing code, browsing the web, and interacting with any service that exposes an API. In the MCP ecosystem, each tool is exposed through an MCP server that the agent discovers and connects to. The number of available MCP servers has grown rapidly, covering major enterprise platforms (Salesforce, ServiceNow, Jira, Confluence, Slack, Google Workspace, Microsoft 365) as well as infrastructure services (AWS, Azure, GCP) and developer tools (GitHub, GitLab, databases, monitoring platforms).

• Data connectors provide the agent with access to organisational knowledge: document repositories, knowledge bases, databases, and data lakes. RAG pipelines are the most common pattern, where the agent queries a vector database to retrieve relevant documents and includes them in its context before generating a response or plan. The data connector layer is where data governance controls are critical: the agent should access only the data it is authorised to use for the current task, and the retrieval mechanism should respect the access controls that apply to the underlying data sources.

• Agent-to-agent connectors, standardised through the A2A protocol, allow agents to discover each other’s capabilities, delegate tasks, and coordinate workflows. These connectors enable the multi-agent architectures discussed later in this post, where specialised agents collaborate on complex workflows that exceed the capability of any single agent.

• Identity and authentication connectors provide the agent with the credentials it needs to access external services. These include OAuth 2.0 flows (on-behalf-of for delegated user permissions, client credentials for the agent’s own identity), token vaults (centralised credential management for multiple services), and workload identity federation (cross-platform authentication without stored secrets). The identity connector layer determines who the agent authenticates as, what permissions it holds, and how its actions are attributed in audit logs.

From Assistants to Autonomous Agents

The evolution from chatbots to enterprise-grade autonomous agents has followed a trajectory that mirrors the broader history of distributed computing. Chatbots receive a prompt and return text. Single agents receive a goal, select tools, and execute actions against external systems. Multi-agent systems involve multiple specialised agents (planning, retrieval, execution, evaluation, escalation) collaborating on complex workflows, with delegation chains and orchestration patterns that resemble the shift from monolithic applications to microservices.

The analogy to microservices is useful because it highlights both the architectural benefits (specialisation, composability, independent scaling) and the operational challenges (observability, debugging, cascading failures, service mesh governance) that multi-agent systems inherit. Organisations that went through the microservices migration understand that distributing functionality across independent services creates coordination complexity that does not exist in a monolith. The same dynamic applies to distributing cognitive tasks across independent agents.

Understanding how agentic NHIs differ from traditional non-human identities (service accounts, API keys, managed identities) is important for determining what governance controls apply.

Examples of enterprise use cases where multi-agent architectures are moving into production include supply chain optimisation (agents monitoring inventory levels, coordinating procurement, and adjusting logistics across multiple systems), customer service resolution (triage agents routing inquiries, knowledge retrieval agents searching documentation, resolution agents executing actions, escalation agents engaging human support), internal workflow automation (onboarding workflows spanning HR, IT, facilities, and security systems), and cross-system orchestration (agents coordinating processes across ERP, CRM, and legacy applications that were never designed to interoperate through AI).

The Emerging Protocol Stack

The communication infrastructure for agentic AI is forming around two primary protocols and a set of emerging extensions. This section describes what is settling and where the architecture remains experimental.

MCP: agent-to-tool connectivity

The Model Context Protocol, originally created by Anthropic and now governed by the Linux Foundation, standardises how agents discover, connect to, and interact with external tools, APIs, and data sources. MCP provides a universal connector that reduces integration cost: rather than building custom integrations for each tool, developers build an MCP server for the tool and any MCP-compatible agent can use it. The analogy to USB-C as a universal hardware connector captures the basic intent.

MCP is the most mature layer of the agentic protocol stack. With 97 million SDK downloads and implementations across Anthropic, OpenAI, Google, Microsoft, and AWS, it has achieved the critical mass needed for an ecosystem standard. MCP compliance is appearing in enterprise RFPs as organisations seek to prevent vendor lock-in in their agent infrastructure.

The security posture of the MCP ecosystem remains a concern. Research from Check Point and Wiz found that approximately 40% of the roughly 10,000 MCP servers reviewed contained security weaknesses. GitGuardian detected over 24,000 secrets exposed in MCP configuration files in the protocol’s first full year of mainstream adoption, driven partly by documentation that often encourages hardcoding API keys directly into configuration files. The Smithery.ai vulnerability documented by Wiz exposed an overprivileged token granting arbitrary code execution across all 3,000+ hosted MCP servers. MCP has achieved protocol maturity. Security maturity is lagging behind.

A2A: agent-to-agent communication

The Agent-to-Agent protocol, created by Google Cloud in April 2025 and transferred to Linux Foundation governance in June 2025, standardises how agents discover each other, delegate tasks, and coordinate workflows. A2A introduces agent cards (structured capability descriptions that agents publish for discovery), task delegation primitives, and workflow coordination mechanisms. Where MCP handles vertical connectivity (agent to tool), A2A handles horizontal connectivity (agent to agent).

A2A has more than 150 organisations in production use, with backing from Atlassian, Salesforce, SAP, ServiceNow, PayPal, and other enterprise SaaS providers. It is relatively less mature than MCP, but is gaining adoption rapidly in multi-agent enterprise scenarios.

The three-layer stack

The emerging consensus architecture positions MCP as the agent-to-tool layer, A2A as the agent-to-agent layer, and a set of commerce-oriented protocols (ACP, UCP) for transactional use cases that most enterprise implementations have not yet reached. For most organisations, the practical guidance is: start with MCP for single-agent tool connectivity, add A2A when multi-agent orchestration is required, and evaluate commerce protocols only when the use case involves autonomous transactional activity.

The protocols define how agents communicate. They do not define how agents are governed. MCP standardises the communication between an agent and a tool. It does not enforce that the agent has appropriate permissions to use that tool, that the agent’s credentials are properly managed, or that the agent’s actions are logged with sufficient attribution. A2A standardises how agents discover and coordinate with each other. It does not establish trust between them, verify their identities, or enforce that delegation chains respect organisational access policies. The governance layer must be implemented above and below the protocols.

Architecture Patterns in Practice

The architectural patterns emerging in enterprise agent deployments reflect different levels of complexity and governance maturity. Most organisations are at the earliest stage, and the pattern they choose determines the governance challenges they will face.

Single agent with tools

The most common current pattern. One LLM-based agent connected to external tools via MCP. Well-understood, relatively containable from a governance perspective, and adequate for most current enterprise use cases. The core security controls for this pattern include dedicated agent identity, least-privilege scoping, human-in-the-loop controls for sensitive actions, comprehensive audit trails, and blast radius limitation.

Orchestrated multi-agent systems

Multiple specialised agents coordinated by a planner or router agent. This pattern introduces governance challenges that do not exist in single-agent deployments.

Multi-agent governance challenges

• Delegation chain accountability :Agent A delegates to Agent B, which delegates to Agent C. Who authorised the full chain? The initiating user may have authorised Agent A, but did they implicitly authorise the downstream agents that Agent A chose to invoke? The authorisation model needs to account for multi-hop delegation, and the audit trail needs to record the full chain with attribution at each step.

• Privilege accumulation: Each agent in a delegation chain may have its own permission scope. When agents collaborate, the effective permission of the workflow may be the union of all participating agents’ permissions, which can exceed what any individual agent or the initiating user was intended to have. This is the agent equivalent of privilege escalation, and it can occur without any agent individually exceeding its own permissions.

• Cascading failures: In a multi-agent workflow, one agent’s failure (a hallucinated output, a misinterpreted instruction, a compromised tool call) propagates through the chain. Downstream agents operate on the flawed output without the context to know it is flawed. The failure cascades before any monitoring or human oversight can intervene, particularly in workflows designed for speed.

• Attribution complexity: When a five-agent workflow produces a harmful output, which agent is responsible? The planning agent that decomposed the task? The retrieval agent that provided biased data? The execution agent that took the action? The evaluation agent that approved the result? Attribution in multi-agent systems requires end-to-end tracing of the reasoning and decision chain, which is technically demanding and not well supported by current observability tooling.

Infrastructure patterns

Several infrastructure patterns are emerging alongside the agent architectures themselves. AI gateways are being deployed as governance enforcement points between agents and external services, analogous to API gateways in microservices architectures. These gateways can enforce policy (blocking agents from accessing unapproved services), manage credentials (rotating and injecting credentials so agents never hold long-lived secrets), and capture audit data (logging every tool call and agent interaction at the gateway layer).

Knowledge graphs are emerging as the semantic integration layer for multi-agent systems, providing shared context and truth boundaries that prevent agents from operating on stale, conflicting, or fabricated information. Dedicated observability layers are being built for agent-specific telemetry: reasoning traces, tool call sequences, delegation chains, and goal-state tracking, which are distinct from the API latency and error rate metrics that conventional application monitoring provides.

Design principles converging in production deployments include API-first, cloud-native architectures for composability and vendor portability, domain-specific models outperforming frontier models in regulated sectors where precision and auditability matter more than general capability, security-by-design as a prerequisite rather than a retrofit, and cost optimisation for AI resource management, because agent compute costs can spiral in multi-agent architectures where each step in a workflow incurs inference costs.

The Identity and Governance Gap

Agents are non-human identities, but they are NHIs with characteristics that existing NHI governance was not designed for. Standard NHI governance practices (inventory, ownership, credential hygiene, access reviews, monitoring) apply as the baseline, but the cadence and mechanisms need to be different for agents that are ephemeral, dynamic, and autonomous.

A recent post from the Identity Architecture series covered NHIs in detail.

The NHI lifecycle adapted for agents

The lifecycle for agentic NHIs extends the conventional NHI lifecycle across five phases, each adapted for the characteristics that distinguish agents from traditional service accounts and API keys.

• Discovery and provisioning: How agents are registered and catalogued in the organisation’s identity infrastructure. For persistent agents, this is similar to conventional NHI provisioning: an identity is created, an owner is assigned, and the purpose is documented. For ephemeral agents (spun up for a task, destroyed on completion), the provisioning must be automated and the catalogue must track agents that may exist for only minutes. Shadow agents (deployed without formal governance) need to be discovered through the same mechanisms used to detect shadow AI in the broader governance programme.

• Identity establishment: Every agent should have its own identity, distinct from the initiating user and distinct from generic service accounts. Platform implementations are emerging: Microsoft Entra Agent ID introduces agent identity as a first-class object in Entra ID, and Auth0 Auth for GenAI provides developer-oriented agent identity with token vault management and fine-grained access control. For multi-agent systems, identity establishment extends to the relationships between agents: Agent A needs to verify Agent B’s identity before delegating a task, and the identity infrastructure needs to support this agent-to-agent authentication.

• Authentication and authorisation: Continuous verification under Zero Trust principles. For agents, this means evaluating the agent’s identity at every interaction, applying dynamic permission scoping based on the current task (the same agent may need different permissions for different tasks), and verifying that delegation chains are authorised. Workload identity federation provides one mechanism for cross-platform agent authentication without stored credentials.

• Runtime governance: Monitoring and controlling agent behaviour during execution. This includes observability (reasoning traces, tool call logs, delegation chain records), boundary enforcement (ensuring the agent operates within its defined scope), human-in-the-loop controls (requiring approval for high-consequence actions), and automated containment (terminating an agent that exhibits anomalous behaviour). Runtime governance is where the AI gateway pattern provides the most value, as a policy enforcement point that sits between the agent and the systems it interacts with.

• Decommissioning: Cleanup of credentials, revocation of permissions, termination of delegation chains, and preservation of audit records. For ephemeral agents, decommissioning should be automated as part of the agent’s lifecycle. For persistent agents, decommissioning follows the same process as conventional NHI decommissioning but with additional consideration for any downstream agents or workflows that depend on the decommissioned agent.

The Threat Environment

The threat environment for agentic AI extends beyond conventional AI threats (prompt injection, data poisoning, model extraction) into territory that reflects the autonomous, connected, and delegating nature of agents.

NIST’s risk categories

NIST’s January 2026 RFI on AI agent security articulated three risk categories that now anchor the emerging control framework. Adversarial data interaction covers risks where adversary-controlled content manipulates agent behaviour, with prompt injection as the canonical example: malicious instructions embedded in data the agent retrieves as part of legitimate task execution. NIST’s framing treats prompt injection as a distinct vulnerability class where the agent’s own reasoning capability becomes the attack surface. Insecure model vulnerabilities covers compromise through the model itself, including data poisoning, backdoor attacks, and model extraction. Insecure deployment configuration covers excessive permissions, inadequate monitoring, and missing boundary controls.

Agent-specific vectors

Several threat vectors are specific to agentic architectures and do not have direct parallels in conventional AI or traditional software systems.

Autonomous exfiltration occurs when an agent with both data access and external communication capability can exfiltrate data without explicit instruction, either through manipulation (indirect prompt injection) or through goal misalignment (the agent interprets its objective in a way that leads it to transmit data externally). Privilege accumulation in delegation chains, as described earlier, allows the effective permission scope of a multi-agent workflow to exceed what any individual participant was intended to have. Cascading goal misalignment in multi-agent systems occurs when one agent’s subtly misaligned objective propagates through coordinated workflows, producing outcomes that no single agent intended.

Tool definition poisoning in the MCP ecosystem is a supply chain attack where compromised MCP servers provide altered tool definitions that redirect agent tool calls to attacker-controlled endpoints or modify the semantics of existing tools. MITRE ATLAS added “Publish Poisoned AI Agent Tool” as a specific technique in its February 2026 v5.4.0 update, reflecting the operational reality of this threat. The “Escape to Host” technique added in the same update catalogues how agent systems with code execution capabilities can break out of their intended operational context.

CSA MAESTRO

The Cloud Security Alliance’s MAESTRO framework (Multi-Agent Environment, Security, Threat, Risk, and Outcome) provides the most comprehensive threat modelling framework purpose-built for agentic AI. MAESTRO defines a seven-layer reference architecture spanning Foundation Models, Data Operations, Agent Frameworks, Deployment Infrastructure, Agent Identity and Access, Agent Orchestration, and Agent Ecosystem. Each layer has its own threat profile, and the framework’s key insight is that the most dangerous attack paths chain across layers, starting at the foundation model and cascading through the orchestration and ecosystem layers.

MAESTRO has already been applied to real-world systems including OpenAI’s Responses API and Google’s A2A protocol, demonstrating its practical utility for threat identification. The CSA has indicated that MAESTRO v2, expected in 2026, will focus on practical implementation guidance. The OWASP Top 10 for Agentic Applications and the OWASP Multi-Agentic System Threat Modeling Guide (which applies the MAESTRO framework) provide complementary practitioner-level resources for teams conducting threat assessments of their agent deployments.

Governance Frameworks Taking Shape

The governance infrastructure for agentic AI is being built in parallel with the systems it needs to govern. Several frameworks are developing, and while none is complete, together they are defining the shape of what mature agentic governance will require.

NIST AI Agent Standards Initiative

The Initiative, launched in February 2026, is organised around three pillars: facilitating industry-led technical standards with US leadership in international bodies such as ISO/IEC JTC 1, supporting community-led open-source protocol development co-invested with NSF, and conducting fundamental research in AI agent security, identity infrastructure, and interoperability evaluation.

The NCCoE concept paper on agent identity and authorisation is the most operationally relevant output for enterprise security teams. It directly addresses the gap where AI agents are commonly treated as generic service accounts with no dedicated identity, authorisation, or accountability controls. The COSAiS project is developing SP 800-53 control overlays for five AI deployment categories including single-agent and multi-agent systems. Sector-specific listening sessions in healthcare, finance, and education took place in April 2026. The AI Agent Interoperability Profile, targeted for Q4 2026, will be the initiative’s first comprehensive normative output.

The Foundation for Defense of Democracies’ March 2026 response to the NIST RFI raised a concern worth noting: current threat frameworks do not model agentic attack patterns at sufficient granularity for purple-team exercises or detection engineering. Organisations should consider investing in threat modelling using emergent agentic attack taxonomies (MAESTRO, MITRE ATLAS agentic techniques, OWASP Agentic Top 10) as a parallel track to adopting official guidance, because the official guidance will take time to mature while the threat is present now.

Zero Trust for agents

Zero Trust principles (never trust, always verify, assume breach) apply to agents, but the implementation differs from conventional Zero Trust architectures. Continuous verification means evaluating agent behaviour at runtime, assessing whether the agent’s actions are consistent with its stated purpose and approved scope, which requires behavioural monitoring that goes beyond authentication. Micro-segmentation means scoping each agent’s access to the specific tools and data it needs for the current task, which requires dynamic permission boundaries that adjust per invocation. Least privilege means permission scoping that reflects the agent’s current task rather than a static role assignment that covers all possible tasks the agent might perform.

Research on Zero Trust for NHIs in IoT environments (Mthethwa et al., 2026) proposes a five-step implementation framework: define NHI boundaries, implement robust identity and access management, establish continuous monitoring, develop threat detection capabilities, and create incident response protocols. This framework transfers to agentic AI with adaptation: the boundary definition must account for delegation chains, the access management must support dynamic scoping, the monitoring must include reasoning-layer observability, and the incident response must account for multi-agent cascading failures.

Governance gaps that remain open

Several governance challenges remain unresolved at the framework level. Multi-agent accountability (determining responsibility when a chain of agents produces a harmful outcome) has no established model. Cross-boundary trust (establishing trust between agents operating across organisational or jurisdictional boundaries) is an active research area with no standard solution. Ephemeral identity governance (governing identities that exist for minutes or hours and may never be reviewed by a human) challenges the periodic access review model that underpins most identity governance programmes. Behavioural verification (confirming that an agent is doing what it claims to be doing, given that its reasoning is opaque) is a fundamental limitation of current AI technology. These gaps do not prevent organisations from deploying agents, but they do require compensating controls and honest risk acceptance.

What Practitioners Should Do Now

The standards are developing, the protocols are maturing, and the governance frameworks are being written. Four actions apply regardless of which specific standards or protocols ultimately prevail.

Immediate actions for agentic AI governance

1. Inventory all agents currently deployed or being piloted. Include their purpose, the systems they access, the permissions they hold, and who owns them. Include agents embedded in SaaS platforms (Copilot features, workflow automation, AI assistants with tool access) that may not be formally classified as agents but have the characteristics of agents. You cannot govern what you cannot see.

2. Apply the NHI governance baseline: every agent gets its own identity, permissions follow least privilege, credentials are short-lived and automatically managed, and all actions are logged with attribution to both the agent and the initiating user. For multi-agent systems, extend the audit trail to capture the full delegation chain.

3. Audit MCP security posture for any agent-to-tool integrations. Check MCP server configurations for hardcoded credentials. Bring MCP infrastructure within scope of existing secrets management, vulnerability management, and asset inventory controls. Apply the same standards to MCP servers as to any other production service endpoint.

4. Start threat modelling agent deployments using CSA MAESTRO. Even as the framework continues to develop, the seven-layer model provides a structured approach to identifying threats that conventional threat models miss. Supplement with MITRE ATLAS agentic techniques and the OWASP Agentic Top 10 for specific attack patterns and mitigations.

The NIST AI Agent Interoperability Profile (Q4 2026) and MAESTRO v2 are the next major milestones to watch. The COSAiS SP 800-53 control overlays will provide the first formal mapping of agent-specific controls to an established security control framework. Organisations with operational experience deploying agents have an opportunity to influence the direction of these standards through participation in NIST listening sessions, RFI responses, and industry working groups.

The agentic enterprise is arriving faster than the governance infrastructure designed to support it. That gap will close as standards mature, but the agents being deployed today will not wait for the standards to catch up. The practical approach is to apply the governance principles that are settled (dedicated identity, least privilege, auditability, Zero Trust), monitor the standards that are developing, and design agent architectures with sufficient modularity that they can adapt as the governance requirements solidify.

Parts 2 through 4 of this series covered how identities are created, how they authenticate, and how their sessions and credentials are managed. This post covers what happens after access is granted: how it is reviewed, how it changes when the person’s role changes, and how it is removed when the relationship ends. Identity governance is the control layer that closes the gap between what access a person has and what access they should have.

Without active governance, permissions accumulate. A user who moves from finance to marketing retains their finance entitlements because no one explicitly revoked them. A contractor whose engagement ended six months ago still has an active guest account. An application role that was granted for a specific project remains assigned long after the project concluded. Over time, the gap between actual access and intended access widens, and with it the organisation’s exposure to both security risk and audit findings.

This post covers two platforms in depth because the choice between them, or the decision to use both, is one of the more consequential architectural decisions in this space. Entra ID Governance is Microsoft’s native governance capability, tightly integrated with the Entra directory, Conditional Access, and PIM. SailPoint Identity Security Cloud is a cross-platform governance solution that aggregates identities and entitlements from Entra ID, on-premises AD, SaaS applications, and legacy systems into a unified governance model.

Access Packages

Access packages are Entra ID Governance’s mechanism for bundling related resources into a single requestable unit with defined lifecycle policies. Rather than granting individual group memberships, application role assignments, and SharePoint site permissions one at a time through separate processes, an access package combines them into a coherent set that can be requested, approved, assigned, and expired as a unit.

How they work

An access package is defined in the Entra admin centre or via Microsoft Graph. It contains one or more resource roles: Entra ID groups, application roles for enterprise applications registered in Entra, SharePoint Online sites, or Entra ID roles (in preview). An assignment policy controls who can request the package, whether approval is required (and how many approval stages), whether the requestor must provide a justification, how long the assignment lasts before automatic expiry, and whether the assignment can be renewed.

When a user requests an access package, the approval workflow fires. The designated approver (a manager, a resource owner, or a specific named approver) receives a notification, reviews the request and justification, and approves or denies it. If approved, the user receives all the resource roles in the package. When the assignment expires (or is revoked), all resource roles are removed automatically.

Connected organisations

Access packages can be made available to external users from connected organisations. A partner organisation is registered as a connected organisation in Entra ID Governance, and its users can request access packages through a self-service portal (myaccess.microsoft.com). This provides a governed alternative to ad hoc guest account creation: instead of an employee inviting a guest and manually assigning permissions, the external user requests the specific access they need, the request goes through an approval workflow, the access has a defined expiry, and the entire process is logged.

This directly addresses the stale guest account problem discussed in Part 2. Guest access is no longer open-ended; it is time-bound and reviewable by design.

Where access packages work well, and where they do not

Access packages are effective for project-based access (a consultant needs access to a SharePoint site, a Teams channel, and a specific application for 90 days), role-based onboarding bundles (new starters in the finance team receive a standard set of applications), and governed external collaboration. They are less effective for fine-grained entitlements within applications, because they operate at the group and application role level rather than at the level of individual permissions inside an application. They also do not natively cover on-premises AD groups or non-Microsoft SaaS applications without additional configuration through SCIM provisioning or custom connectors. For environments where governance needs to span these boundaries, SailPoint provides the broader coverage, which is addressed later in this post.

Access Reviews

Access reviews are the periodic recertification mechanism in Entra ID Governance. They ask a designated reviewer to confirm whether each user’s access to a specific resource is still appropriate, and they can be configured to automatically remove access when reviewers do not respond.

Configuration

An access review is created for a specific scope: members of a group, users assigned to an application, users with an Entra directory role, users with an Azure resource role, or users assigned to an access package. The reviewer can be the user’s manager (looked up from the reporting structure in Entra), the resource owner (the group or application owner), the users themselves (self-attestation), or a specific named reviewer.

Reviews can be one-time or recurring (weekly, monthly, quarterly, semi-annually, annually). The review period defines how long reviewers have to complete their decisions. When a reviewer does not respond within the period, the configuration determines what happens: the access is automatically approved (the least secure option), automatically denied and removed (the most secure), or left unchanged (which defers the decision but leaves potentially inappropriate access in place).

Multi-stage reviews add a second layer: the first stage might be self-attestation (the user confirms they still need the access), and the second stage is manager review (the manager confirms the user’s claim). This distributes the review burden while maintaining oversight.

Practical challenges

Access reviews are conceptually sound but operationally difficult to sustain. Three problems recur in most deployments.

Reviewer fatigue is the most common. A manager responsible for 30 direct reports, each with memberships in 10 or more groups, faces a review set of 300 or more individual decisions every quarter. Without tooling that highlights which memberships are unusual or risky, the review becomes a rubber-stamp exercise where the reviewer clicks “Approve” on everything to clear the queue. Mitigations include using machine learning-based recommendations (Entra ID Governance provides these, flagging users whose access patterns differ from their peers), reducing the review scope to high-risk resources rather than reviewing everything, and setting auto-deny on non-response to create a natural consequence for not completing the review.

Context deficit is the second problem. The reviewer sees a user name and a group name, but may not understand what the group provides access to. A group called “SG-Finance-ReadWrite” is somewhat self-explanatory. A group called “APP-PRD-XJ7-Users” is not. Governance teams can address this by maintaining descriptions on groups and applications, and by providing reviewers with supplementary information (when the access was granted, who approved it, when it was last used) to support informed decisions.

The third problem is the gap between group membership and effective permissions. A user may be a member of a group that grants access to a SharePoint site. Within that site, they may have been granted additional direct permissions by a site owner. The access review covers the group membership but not the direct permissions, which means the review provides an incomplete picture of the user’s actual access. This is one of the areas where a cross-platform governance tool like SailPoint provides additional value, because it can aggregate both group-based and direct entitlements into a single review.

Guest user reviews

Access reviews for guest users deserve specific attention because of the stale account problem described in Part 2. A review scoped to all users with userType = Guest can be configured with the sponsor or inviting user as the reviewer and auto-removal on non-response. This creates a recurring cleanup mechanism: if the person who invited the guest cannot confirm the guest still needs access (or does not respond at all), the guest’s access is removed automatically. Combined with access packages that have defined expiry periods, this provides a two-layer defence against guest account accumulation.

Lifecycle Workflows

Lifecycle workflows automate the joiner-mover-leaver process by executing predefined tasks in response to identity lifecycle events. The trigger is typically an attribute change in the HR system (Workday, SAP SuccessFactors, or a custom source connected via the inbound provisioning API), which propagates to Entra ID and fires the appropriate workflow.

Workflow categories

• Joiner: Triggered when a new employee record appears. Tasks include: enable the Entra account, add the user to groups based on department and job title, assign access packages for the user’s role, generate a Temporary Access Pass for initial credential setup, and send a welcome notification with onboarding instructions.

• Mover: Triggered when an employee’s department, job title, or location changes. Tasks include: add the user to groups for the new role, trigger an access review for entitlements from the previous role, and assign new access packages. Mover workflows are the most complex to design because “what should change” depends heavily on the organisation’s role model and whether the previous entitlements should be retained, reviewed, or immediately removed.

• Leaver: Triggered when an employee’s termination date is reached or their employment status changes. Tasks include: disable the account, revoke all active sessions, remove all access package assignments, remove the user from groups, block sign-in, transfer the user’s OneDrive content to their manager, and delete the account after a retention period (typically 30 to 90 days).

The effectiveness of lifecycle workflows depends entirely on the reliability of the HR integration. If the HR system does not communicate terminations promptly, the leaver workflow fires late and the departed employee retains access in the gap. A compensating control is to run a scheduled workflow that queries for accounts whose employment end date has passed but whose accounts are still enabled, and disable them regardless of whether the HR event has propagated.

Lifecycle workflows can also be extended with custom tasks via Azure Logic Apps or Azure Functions, which allows organisations to integrate non-Microsoft systems into the workflow. For example, a leaver workflow could call a ServiceNow API to create a ticket for hardware retrieval, or call a SaaS application’s user management API to deprovision the account.

SailPoint Identity Security Cloud

Entra ID Governance covers provisioning, access packages, reviews, and lifecycle workflows for resources within the Entra ecosystem. For organisations whose governance requirements extend beyond that boundary, SailPoint Identity Security Cloud provides cross-platform identity governance by connecting to multiple identity sources and target systems, aggregating identities and entitlements into a unified model, and running governance processes across the full estate.

The identity warehouse

SailPoint’s core differentiator is the identity warehouse: an aggregated view that correlates user accounts from Entra ID, on-premises AD, ServiceNow, SAP, Workday, Salesforce, Oracle, mainframe systems, and other connected sources into a single identity record. Each identity has a consolidated list of entitlements gathered from all connected systems. This aggregated view is what enables cross-platform governance. A certification campaign in SailPoint can present a reviewer with a single view of a user’s access across Entra, AD, SAP, and ServiceNow, rather than requiring separate reviews in each system.

The warehouse model also enables analytics that are not possible when governance data is fragmented across systems. SailPoint can identify users who have entitlements that differ significantly from their peers in the same department (potential over-provisioning), entitlements that have not been used within a defined period (candidates for removal), and accounts that exist in a target system but are not correlated to an identity in the warehouse (orphaned accounts).

Role mining and role modelling

Role mining analyses the existing entitlement data across the user population to identify patterns. If 95% of users in the finance department hold the same five entitlements across three systems, SailPoint can suggest formalising that pattern as a “Finance” role. Role modelling allows administrators to define roles based on business function and assign entitlements to those roles. When a user is assigned a role (either manually or automatically based on HR attributes), they receive all the entitlements associated with it. When the role is revoked, the entitlements are removed.

Role-based access is the primary mechanism for reducing entitlement creep. Instead of accumulating ad hoc permissions over time through individual requests, users receive structured, role-based access that is easier to review and easier to revoke. The practical challenge is building and maintaining the role model: roles need to reflect actual business functions, they need to be updated when those functions change, and the number of roles needs to remain manageable (role explosion, where hundreds of narrow roles are created, undermines the simplification that roles are supposed to provide).

Certification campaigns

A certification campaign is SailPoint’s equivalent of an access review, with broader scope. Where Entra access reviews operate on individual resources (a group, an application, an Entra role), SailPoint certifications can span the user’s entire entitlement set across all connected systems in a single review cycle. The campaign can be configured with escalation rules (if the primary reviewer does not respond within a defined period, the review is escalated to their manager or to a security team member), auto-revocation policies for unresponded items, and exception handling (certain entitlements can be flagged as requiring additional justification rather than a binary approve/deny decision).

Certifications can also be targeted. A campaign can focus on a specific population (all users in a department that recently restructured), a specific entitlement (all users with access to a sensitive system), or a specific risk signal (all users flagged as having entitlements inconsistent with their peers). This targeting reduces reviewer fatigue by focusing the review on the access that is most likely to be inappropriate.

Separation of duties

Separation of duties (SoD) policies define combinations of entitlements that should not be held by the same person. The canonical example is financial controls: a user should not have both “create purchase order” and “approve purchase order” permissions in the ERP system, because that combination enables fraud. SoD is a regulatory requirement in many industries (SOX compliance, banking regulations) and a security best practice in all environments.

SailPoint evaluates SoD policies at two points: during provisioning (blocking a conflicting entitlement before it is granted, or flagging it for a risk-aware approval) and during certification (surfacing existing SoD violations to reviewers for remediation). Entra ID Governance does not provide native SoD enforcement, which is one of the primary reasons organisations adopt SailPoint alongside Entra. Without SoD controls, conflicting entitlements can be granted through separate access packages or manual assignments without any system flagging the conflict.

When to Use Each, and When to Use Both

Entra ID Governance is the right choice for Microsoft-centric environments where the majority of applications are cloud-based and integrated with Entra ID, the identity lifecycle is driven by a single HR source, and the governance requirements are met by access packages, access reviews, and lifecycle workflows. It is included in certain Microsoft licensing tiers, reducing the incremental cost for organisations already invested in the Microsoft ecosystem.

SailPoint is the right choice when the environment includes significant non-Microsoft systems (SAP, Oracle, mainframe, custom applications), when cross-platform certification campaigns are required, when SoD policies need to be enforced across multiple systems, or when role mining and modelling capabilities are needed to rationalise a complex entitlement structure. SailPoint requires dedicated implementation effort, ongoing operational investment (connector configuration, role modelling, campaign design), and its own licensing.

Many organisations use both. The typical pattern is Entra ID Governance handling provisioning, access packages, and lifecycle workflows for cloud applications (because it is natively integrated and already licensed), while SailPoint provides the aggregated governance view, cross-platform certifications, and SoD enforcement across the full estate. The integration between the two works through SailPoint reading Entra’s directory and audit data as one of its connected sources, and optionally provisioning access back to Entra via SCIM or Graph API.

Incorporating Non-Human Identities

Part 4 of this series covered the non-human identity population: service accounts, managed identities, application registrations, API keys, and AI agent identities. Governance for these identities should not be treated as a separate programme. Access reviews and certification campaigns should include non-human identities alongside human identities, and the same lifecycle management discipline (creation with an owner, periodic review, decommissioning when the purpose is served) should apply.

In Entra ID Governance, access packages can now be assigned to agent identities as discussed in Part 4, with the same approval workflows and automatic expiry policies used for human identities. Service principals can be included in access review scopes for application role assignments. SailPoint’s newer connectors support aggregating service principal entitlements from Entra ID into the identity warehouse, allowing them to appear in certification campaigns alongside human user entitlements.

The coverage is not yet complete. Most governance tooling was designed for human identities and is being extended to NHIs incrementally. The practical step is to include NHIs in the governance programme now, using whatever coverage the current tooling provides, rather than waiting for full feature parity before starting.

Logging, Audit, and Reporting

Governance reporting is often the interface between the identity team and the compliance or risk function. The reports need to answer specific questions: who has access to this system and why, when was that access last reviewed, who approved it, and is there a documented business justification. If the governance platform cannot produce these reports reliably, the compliance value of the entire programme is reduced.

Entra ID audit logs capture access package assignments and removals, access review decisions (approve, deny, no response with auto-action), lifecycle workflow executions (which tasks ran, which succeeded, which failed), and PIM role activations and deactivations. These logs can be exported to Azure Monitor (Log Analytics), Microsoft Sentinel, or a third-party SIEM via Entra diagnostic settings. Retention in Entra’s native logs is limited (30 days for sign-in logs, 30 days for audit logs in free tier, longer with premium licensing), so archival to a separate store is necessary for compliance obligations that require longer retention.

SailPoint provides certification completion reports (which reviewers completed their reviews, which did not, what the approval rate was), SoD violation reports (current violations, remediation status, exceptions), entitlement change audit trails (what changed, when, by whom), and identity risk analytics (users with anomalous entitlement profiles, orphaned accounts, unused entitlements). These reports can be exported and integrated with the organisation’s GRC (governance, risk, and compliance) tooling.

Both log streams should feed into the same SIEM used for authentication and security monitoring. An access review that removes a user’s access should correlate with the absence of subsequent authentication events from that user for the revoked application. A lifecycle workflow that disables a departed employee’s account should correlate with a session revocation event. When these events do not correlate (access was revoked in the governance system but the user is still authenticating), it indicates a gap in the provisioning chain that needs investigation.

Series Conclusion

This post completes the five-part series on identity architecture for the modern enterprise. Part 1 established the distinction between workforce and customer identity and mapped the architectural divergences between them. Part 2 provided a reference architecture for workforce identity, covering directory design, Conditional Access, authentication, session management, and external collaboration. Part 3 provided the equivalent for customer identity, covering registration flows, passkey adoption, session management, privacy controls, and fraud detection. Part 4 covered non-human identities, from legacy service accounts to AI agent credentials, and the governance gap that exists across the NHI population. This final part covered the governance layer that ensures access remains appropriate over time, using both Entra ID Governance for Microsoft-centric environments and SailPoint for cross-platform governance.

The thread that runs through all five posts is that identity architecture is not a single discipline. Workforce identity, customer identity, and non-human identity each operate under different constraints, serve different populations, and are subject to different regulatory and operational requirements. Building an architecture that serves all three well requires understanding those differences and making deliberate design decisions for each domain, rather than applying a single set of patterns across all of them.

Identity Architecture for the Modern Enterprise:

A five-part series covering workforce and customer identity architecture, phishing-resistant MFA, and identity governance.

• Part 1: Why Two Architectures

• Part 2: Workforce Reference Architecture

• Part 3: Customer Reference Architecture

• Part 4: Non-Human Identities in the Workforce

• Part 5: Workforce Identity Governance

The first three parts of this series covered identity architecture for people: workforce users in Part 2, customers in Part 3. This post covers the identities that are not people. Service accounts, managed identities, application registrations, API keys, shared accounts, and the emerging category of AI agent identities collectively form the non-human identity (NHI) population that underpins every integration, automation, and service-to-service communication in an enterprise environment.

NHIs tend to receive less attention than human identities, despite often outnumbering them. The risks they introduce are different in character. NHI credentials are frequently long-lived or non-expiring. They are often over-privileged because they were created for a specific integration during initial setup and never scoped down. They are commonly exempt from the MFA and Conditional Access policies that protect human accounts. And when compromised, they provide persistent, quiet access that does not trigger the behavioural anomaly detections designed for human sign-in patterns. An attacker using a compromised service principal at 3am looks the same as the scheduled job that runs at 3am every night.

The Inventory Problem

Before addressing individual NHI types, it is worth acknowledging the foundational challenge: most organisations do not have a complete inventory of their non-human identities. NHIs are created by different teams (developers, platform engineers, IT operations, security) through different mechanisms (Azure portal, CLI, Terraform, application registration UIs, manually created AD service accounts) and tracked in different systems, or not tracked at all.

A service principal created by a developer three years ago for a proof-of-concept integration may still have Contributor-level access to a production subscription. An on-premises service account created during a 2015 server migration may still hold domain admin privileges. An API key embedded in a CI/CD pipeline configuration may have been copied into a wiki, a Slack message, and three developers’ local environments.

The first step in any NHI programme is discovery: enumerating all non-human identities, their credential types, their permission scopes, their last usage timestamps, and who owns them. In Entra ID, this means querying application registrations, service principals, managed identity assignments, and key/certificate expiry dates via Microsoft Graph. Microsoft Defender for Cloud’s identity posture assessment provides some of this visibility. Third-party NHI platforms (Astrix, Oasis Security, Clutch Security) offer discovery across multi-cloud environments, correlating identities across Entra ID, AWS IAM, GCP, and SaaS applications into a unified inventory.

Without this inventory, every subsequent governance decision is built on incomplete information.

Managed Identities

Managed identities are the preferred pattern for workload-to-service authentication because they eliminate stored credentials entirely. The identity is assigned to the Azure resource (VM, App Service, Function App, AKS pod) and the platform handles token issuance and rotation. There is no client secret to store, no certificate to rotate, and no credential to accidentally commit to a code repository.

Azure provides two types. System-assigned managed identities have a one-to-one relationship with the resource: the identity is created when the resource is created and deleted when the resource is deleted. User-assigned managed identities are standalone identity objects that can be shared across multiple resources, which is useful when several services need the same access (e.g. multiple Function Apps reading from the same storage account).

The equivalent patterns in other clouds are AWS IAM Roles (attached to EC2 instances, Lambda functions, or ECS tasks via instance profiles or execution roles) and GCP service accounts attached to Compute Engine instances or Cloud Run services.

The common mistakes with managed identities are worth noting. First, assigning overly broad roles. A managed identity given Contributor or Owner on a resource group can modify or delete any resource within it. A custom role scoped to the specific operations the workload needs (read from a storage container, write to a queue, query a database) is almost always appropriate. Second, not reviewing managed identity permissions as part of regular access reviews. The identity is managed by the platform, but the permissions are managed by you, and they can drift over time as requirements change. Third, treating managed identity access as inherently safe because the credential is platform-managed. The identity still has whatever permissions you assigned to it, and a compromised workload can exercise those permissions freely.

Application Registrations and Service Principals

For scenarios where managed identities are not available (cross-tenant access, third-party SaaS integrations, on-premises applications calling cloud APIs), Entra ID application registrations with service principals are the standard pattern. An application registration defines the identity and configuration of the application. The service principal is the instance of that application in a specific tenant.

Credential types

Two credential types are available for service principals: client secrets (passwords) and certificates.

Client secrets are simpler to configure but carry well-documented risks. The default maximum expiry in Entra ID is two years, and many organisations accept the default. Secrets are frequently stored in application configuration files, environment variables, or key-value stores where they can be leaked through misconfigured access controls, log output, or source code commits. Rotation is often manual, and when a secret expires, the integration breaks until someone notices and generates a new one.

Certificates are more secure because the private key does not leave the client. Authentication uses the certificate’s private key to sign an assertion, which means the secret material is never transmitted. The trade-off is operational complexity around certificate lifecycle management: issuance, distribution, renewal, and revocation all need to be handled, ideally through an automated PKI or through Azure Key Vault.

Operational practices

Several practices reduce the risk associated with application registrations. Set short expiry periods on client secrets (90 days or less) and automate rotation through Azure Key Vault or a secrets management platform (HashiCorp Vault, AWS Secrets Manager). Monitor for secrets approaching expiry before they cause outages. Alert on new credential additions to existing application registrations, which is a common persistence technique after an attacker compromises a service principal (adding a new secret gives them a credential that the legitimate application owner does not know about).

Workload identity federation

For workloads running outside Azure (GitHub Actions workflows, applications on other cloud providers, Kubernetes clusters), workload identity federation allows the workload to authenticate to Entra ID using a token issued by its own identity provider, without needing a stored client secret. The external identity provider (GitHub, AWS STS, a Kubernetes OIDC issuer) issues a token, and Entra ID trusts that token based on a configured trust relationship. This eliminates client secrets from CI/CD pipelines entirely, which is a significant improvement given that CI/CD credentials are a frequent target for supply chain attacks.

Service Accounts in Active Directory

On-premises service accounts in Active Directory are among the oldest and most poorly governed NHIs in most environments. They were created years or decades ago to run Windows services, scheduled tasks, or batch processes. They often hold domain-wide privileges that were granted during initial setup and never scoped down. Their passwords are frequently set to never expire because rotating them would require updating every service that uses the credential, and the documentation for which services use which accounts has often been lost.

The result is a population of highly privileged, effectively unmanaged identities with static credentials. If an attacker gains access to one of these accounts, they inherit whatever privileges it holds, and there is no MFA, no Conditional Access, and often no monitoring on service account sign-in activity.

Group Managed Service Accounts (gMSAs)

gMSAs are the recommended replacement for traditional service accounts in AD. The domain controller manages the password automatically (rotating it on a 30-day cycle by default), and the hosts authorised to use the account retrieve the current password through a secure channel. There is no manual password management, no password stored in a script or configuration file, and no risk of the password being shared or leaked through documentation.

gMSAs can be restricted to specific hosts, which limits the account’s exposure if one machine is compromised. They support services, scheduled tasks, and IIS application pools on the authorised hosts. The migration path from a traditional service account to a gMSA involves identifying all services that use the account, verifying gMSA compatibility, creating the gMSA, updating the service configurations to use it, and then disabling the original account.

Accounts that cannot be migrated

Some legacy applications do not support gMSAs (applications that require storing the password locally, or that hard-code the credential format). For these, compensating controls are necessary: restrict the account’s logon rights to the specific machines that need it (using the “Log on as a service” and “Deny log on locally” user rights assignments), monitor for any interactive logon attempts (which should never happen for a service account), and integrate the credential into a privileged access management (PAM) vault that enforces checkout/check-in, rotation, and audit logging.

Shared Accounts

Shared accounts are accounts used by multiple people: a shared mailbox account that someone logs into directly, a generic admin account for a SaaS application, a “team” account used to access a vendor portal. They break the auditability model that identity governance depends on. When an action is taken under a shared account, it cannot be attributed to a specific individual, which undermines both security investigation and compliance reporting.

The preferred alternatives depend on the scenario. For shared mailboxes, delegate access to named user accounts rather than sharing a credential for the mailbox account. For SaaS applications, configure SSO and provision named accounts with role-based permissions rather than sharing a single admin login. For vendor portals that only support a single account, some organisations create a named account for each individual and work with the vendor to accommodate that model.

For shared accounts that cannot be eliminated (and there are usually some), compensating controls should include vaulting the credential in a PAM solution, requiring checkout and check-in for each use, recording which individual checked out the credential for each session, and rotating the credential after each use or on a short schedule. The goal is to reconstruct individual attribution even when the account itself does not provide it.

API Keys

API keys are bearer tokens: whoever possesses the key can authenticate as the identity it represents. They are widely used for service-to-service communication and developer access because they are simple to implement and supported by virtually every API. They are also among the most dangerous credential types in an organisation’s environment.

API keys tend to be long-lived (months or years), broadly scoped (full API access rather than specific endpoints), and poorly tracked (created by a developer, stored in a config file, copied into other environments). They frequently end up in source code repositories, CI/CD pipeline definitions, documentation wikis, Slack messages, and support tickets. Once leaked, they provide immediate, unauthenticated access to whatever the key is authorised to reach.

API key hygiene

• Store keys in a secrets manager: Never embed API keys in source code, configuration files, or environment variables directly. Use Azure Key Vault, HashiCorp Vault, AWS Secrets Manager, or the platform’s native secret store. Applications retrieve the key at runtime from the vault.

• Rotate on a schedule: Set a maximum key lifetime (90 days is a reasonable starting point) and automate rotation. Most cloud APIs support having two active keys simultaneously, allowing rotation without downtime: generate a new key, update the consuming application, then revoke the old key.

• Scope to minimum permissions: If the API supports scoped keys (read-only, specific endpoints, specific resources), use the narrowest scope that satisfies the use case. A key that can only read from a single storage container is less useful to an attacker than a key with full administrative access.

• Monitor usage: Track API key usage patterns. Alert on anomalies: requests from unexpected IP addresses, unusual call volumes, access to endpoints the key has not historically been used for. These are indicators of key compromise.

• Prefer OAuth where available: Where the consuming service supports it, replace static API keys with short-lived tokens issued through the OAuth 2.0 client credentials flow. This provides expiring tokens, revocability, and integration with the identity provider’s audit logging. The key distinction is that OAuth tokens expire and must be refreshed, while API keys remain valid until explicitly revoked.

AI Agent Identities

AI agents are the newest and least mature category of NHI. Coding agents, research agents, scheduling assistants, customer service bots, and workflow automation agents all need identities that allow them to authenticate to APIs, access data, and take actions within defined boundaries. The identity requirements are more complex than traditional service-to-service authentication because agents often act on behalf of a specific user, need access to multiple services simultaneously, and may operate autonomously over extended periods.

The current problem

In most deployments today, agent authentication follows one of two ad hoc patterns, neither of which is adequate. In the first, the agent authenticates using a human user’s OAuth token. This means the agent inherits the user’s full permissions rather than a scoped subset, its actions appear in audit logs as if the user performed them directly, and if the token is long-lived, the agent retains access even after the user’s session ends. In the second, the agent authenticates using a service principal with broad API access. This provides no attribution to the user who initiated the agent’s task, and the service principal’s permissions are typically set once and never reviewed.

Both approaches create governance gaps. The identity platforms are responding with purpose-built agent identity constructs.

Microsoft Entra Agent ID and Agent 365

Entra Agent ID, currently in public preview and available through the Microsoft 365 Frontier programme, introduces agent identity as a first-class object type in Entra ID, alongside users, groups, and devices. Each AI agent receives its own identity with several properties that distinguish it from a standard service principal.

Agent identities authenticate via OAuth 2.0 and OIDC using the same protocols as other Entra workload identities, but they are subject to agent-specific Conditional Access policies that can evaluate risk signals tied to agent behaviour (anomalous API call patterns, access from unexpected locations, actions inconsistent with the agent’s defined purpose). Identity Protection generates risk reports specific to agents, and Conditional Access can block or challenge agents flagged as high-risk.

On the governance side, agent identities can be assigned access through access packages in Entra ID Governance, using the same approval workflows and automatic expiry policies used for human identities. When creating an access package assignment policy, administrators can now target agent identities alongside users and service principals. This means agent access is requestable, approvable, time-limited, and reviewable through the same governance mechanisms covered in Part 5 of this series.

Agent 365 sits above Entra Agent ID as the management plane. It provides a centralised inventory of all agents deployed across the organisation, regardless of whether they were built on Microsoft platforms, open-source frameworks, or third-party tools. Agents can be organised into collections with governance policies applied at the collection level. The agent registry, initially accessible in the Entra admin centre, is moving to the Microsoft 365 admin centre under Agent 365 as of May 2026.

The architecture supports three agent types that map to different governance profiles: assistive agents (Copilot-style, operating within a human session with delegated permissions), autonomous agents (operating independently with their own scoped permissions), and user-like agents (representing a persistent digital worker with its own identity lifecycle). Licensing currently requires Microsoft 365 Copilot and the Frontier programme, which positions this as an early-access capability at the time of writing.

Auth0 and Okta

Auth0’s approach to agent identity, Auth for GenAI, has been generally available since November 2025 and takes a developer-oriented approach focused on embedding identity controls into the agent’s application code. It provides user authentication for agents (so the agent can confirm the identity of the user it is acting on behalf of), a Token Vault for secure third-party API access (allowing agents to connect to services like Google Drive, Slack, and GitHub on behalf of users using managed OAuth 2.0 tokens rather than embedded credentials), asynchronous authorisation for long-running tasks (allowing the agent to request human approval for actions that should not be fully automated), and fine-grained authorisation for controlling what data the agent can retrieve based on the user’s permissions.

Okta has also introduced Cross App Access (XAA), a new open protocol extending OAuth for agent-to-app and app-to-app access at scale, with out-of-the-box support in Auth0. XAA is in early access as of January 2026.

The two approaches reflect different positioning. Entra Agent ID treats agent identity as an enterprise governance problem: the agent is a directory object subject to Conditional Access, identity protection, and lifecycle governance. Auth0 treats it as a developer integration problem: the agent is an application that needs to authenticate users and access APIs securely, and the SDK handles the identity layer. For organisations using Entra ID as their workforce identity provider and deploying Microsoft-ecosystem agents, Entra Agent ID provides the tighter integration with existing governance controls. For organisations building custom agents on diverse frameworks or deploying them in customer-facing applications, Auth0’s model may be more practical.

Principles that apply regardless of platform

Agent identity is the least mature area covered in this series. Both platforms are evolving quickly, and current implementations will change. The architectural principles, however, are stable: every agent should have its own identity rather than sharing a human user’s credentials; permissions should follow least privilege and be scoped to the specific actions the agent needs to perform; actions should be auditable with attribution to both the agent and the initiating user; and credentials should be short-lived and automatically managed. These are the same principles that apply to any other NHI, extended to a new category of workload.

Governance and Lifecycle

NHIs should be subject to the same lifecycle management discipline as human identities. In practice, they rarely are. Human identities have HR-driven provisioning and de-provisioning, regular access reviews, and established governance workflows. NHIs are typically created on demand by whoever needs them, with no standard process for documenting the owner, purpose, or intended lifetime, and no mechanism for reviewing or revoking access once the original purpose has been served.

The tooling for NHI governance is improving but is less mature than human identity governance. Entra ID provides workload identity Conditional Access policies that can restrict service principal sign-ins by location or risk. SailPoint and other IGA platforms are extending their coverage to include application registrations and service principals in access reviews and certification campaigns. The third-party NHI platforms mentioned earlier (Astrix, Oasis, Clutch) provide discovery, posture assessment, and lifecycle management across multiple clouds.

Regardless of which tools are used, the governance model should cover the full NHI lifecycle: creation with an assigned owner and documented purpose, permission assignment following least privilege, credential management with enforced expiry and automated rotation, periodic review (quarterly for high-privilege identities, annually for standard), monitoring for anomalous behaviour, and decommissioning when the identity’s purpose has been served.

NHI Governance Checklist

1. Maintain an inventory of all NHIs with owner, purpose, credential type, permission scope, and expiry date.

2. Prioritise migration from static credentials (client secrets, API keys) to managed identities or federated tokens wherever possible.

3. Set maximum credential lifetimes (90 days for client secrets, shorter for high-privilege service principals) and automate rotation.

4. Replace on-premises service accounts with Group Managed Service Accounts (gMSAs) where the application supports them.

5. Eliminate shared accounts where possible. For those that remain, vault the credential and enforce checkout/check-in with individual attribution.

6. Include NHIs in regular access reviews. Query last-used timestamps and flag identities that have not authenticated within a defined window.

7. Alert on new credential additions to existing application registrations (a common persistence technique after compromise).

8. Monitor NHI sign-in activity for anomalies: sign-ins from unexpected locations, unusual API call patterns, activity outside expected hours.

9. Assign every AI agent its own identity with scoped permissions. Do not allow agents to operate using human user tokens or broadly privileged service principals.

10. Document the decommissioning process for each NHI type and execute it when the identity’s purpose has been fulfilled.

Where NHIs Connect to the Rest of the Architecture

NHI governance does not exist in isolation from the workforce and customer identity architectures described in Parts 2 and 3. Service principals access the same cloud resources that workforce users access, and they should be subject to equivalent (or stricter) access controls. Managed identities running in production environments interact with customer data stores that are governed by privacy and consent requirements. AI agents may operate across both workforce and customer identity systems, accessing internal resources through Entra ID and customer-facing APIs through the customer identity platform.

The logging and monitoring infrastructure should treat NHI authentication events as part of the same event stream as human identity events. An attacker who compromises a service principal will use it alongside compromised human credentials, and detecting the attack requires correlating activity across both identity types in the same SIEM. The detection patterns are different (NHI anomaly detection focuses on API call patterns, IP address changes, and credential operations rather than impossible travel or unfamiliar device signals), but they feed into the same investigation workflow.

Part 5 of this series covers workforce identity governance with Entra ID Governance and SailPoint, including how NHIs are beginning to be incorporated into access review and certification processes alongside human identities.

Identity Architecture for the Modern Enterprise:

A five-part series covering workforce and customer identity architecture, phishing-resistant MFA, and identity governance.

• Part 1: Why Two Architectures

• Part 2: Workforce Reference Architecture

• Part 3: Customer Reference Architecture

• Part 4: Non-Human Identities in the Workforce

• Part 5: Workforce Identity Governance

These 15 cybersecurity threat and vulnerability reports, published between October 2025 and April 2026, collectively represent one of the most comprehensive datasets available on the current state of enterprise security. The reports span tens of thousands of incident response engagements, analysis of nearly one trillion AI/ML transactions (Zscaler), over 500,000 hours of incident investigations (Mandiant), firmware-level telemetry from hundreds of millions of endpoint devices (Absolute Security), and direct frontline SOC observations from Australian customer environments (Fortian).

When reports built on different methodologies, different client populations, and different observation points converge on the same findings, those findings carry more analytical weight than any single vendor’s dataset. This post synthesises the convergent themes across all 15 reports and translates them into the priorities that matter most for defenders.

1. Attackers Have Moved Inside the Trust Boundary

The single most consistent finding across all 15 reports is that traditional perimeter-based security assumptions have been operationally invalidated. The mechanism differs by context, but the finding converges from multiple independent data sources.

CrowdStrike reported that 82% of all detections in 2025 were malware-free, up from 51% in 2020. Adversaries rely on legitimate credentials, native administrative tools (LOLBins), and trusted software to blend into normal user behaviour. Blackpoint characterised 2025 as “The Year of Trusted Compromise,” observing that attackers no longer need zero-days, bespoke malware, or elite tradecraft. They repurpose the tools organisations already trust. The Blackpoint SOC disrupted 56% of all incidents before a payload could be deployed, and detected and responded before traditional EDR agents alerted in 72% of cases.

Fortian, observing Australian customer environments, found that phishing emails produced zero successful infostealer infections in 2025. Threat actors have fully migrated to less-governed channels: ClickFix social engineering (42% of observed infostealer infections), SEO poisoning (27%), and malicious YouTube videos (25%). Email security controls are working, but adversaries have moved to channels where those controls do not apply.

Palo Alto Networks Unit 42 found that 87% of intrusions spanned multiple attack surfaces simultaneously, with evidence drawn from endpoints, networks, cloud, SaaS, and identity systems in parallel. Nearly 48% of incidents included browser-based activity, which Unit 42 describes as the new corporate desktop. Mandiant documented adversaries weaponising Group Policy Objects to create scheduled tasks across thousands of endpoints, executing immediately, turning the domain’s own management fabric into a mass-distribution engine for ransomware.

SSL VPN compromise was the most consistently abused initial access vector in Blackpoint’s dataset, with over 60% of SSL VPN abuse incidents assessed as pre-ransomware activity. A single compromised VPN credential provides trusted access to the internal network, enabling discovery, credential theft, lateral movement, and staging with minimal detection friction. Blackpoint’s observation: the attacker does not need to break in when they can log in.

The practical consequence is not that perimeter controls are without value. They remain relevant against technical exploit-driven attacks. The consequence is that a perimeter-first security model is structurally insufficient against an adversary who arrives via valid credentials, a trusted tool installation, or a stolen session token. The model of “assume compromise” that ASD/ACSC recommends for Australian organisations reflects this reality.

Defender priority: detection for machine-speed timelines

The temporal data across reports reinforces the urgency. CrowdStrike reported that the average eCrime breakout time dropped to 29 minutes in 2025, with the fastest observed breakout at 27 seconds. Mandiant found that the handoff time between initial access brokers and secondary threat groups collapsed to under 30 seconds, down from over 8 hours in 2022. Unit 42 documented the fastest 25% of intrusions reaching data exfiltration in just 72 minutes, four times faster than the prior year.

According to Sophos, 37.1% of attacks occur between 11 pm and 3 am, with the four quietest hours falling between 6 am and noon. Exfiltration occurs only 1.87 hours before detection on average. Organisations with daytime-only security operations provide an unmonitored attack window during the hours adversaries prefer.

Automated containment, including identity isolation, network segmentation, and session revocation, must be capable of activating within minutes without requiring analyst approval. The interval between initial access and analyst engagement is now an interval in which an adversary will have already achieved significant objectives.

2. Identity Is the Primary Attack Surface

Across frontline incident response data (Unit 42, Mandiant, Sophos), SOC observations (Fortian, Blackpoint), and credential management research (GitGuardian), identity emerges as the single most reliable entry point for adversaries.

Unit 42 found that identity weaknesses played a material role in nearly 90% of all investigations. Identity served as the way in, the path to privilege escalation, and the mechanism for lateral movement. Sophos reported that MFA was either not enabled or not fully configured in 59.46% of incidents in 2025, the worst year for identity-related root causes in the report’s history. The Sophos data also showed compromised credentials (with nothing further known about the means of compromise) accounting for 42.06% of root causes, with brute-force attacks (15.58%) nearly tied with exploitation of vulnerabilities (16.04%).

Fortian’s Australian SOC data found that 100% of infostealer infections involved theft of browser credentials, with 70% involving theft or attempted theft of API keys and finance-related documents. Infostealers emerged as the dominant enabler of modern attack chains, with 59% of all malware infections observed by Fortian relating to infostealers. This represents a broader shift toward scalable, low-friction identity compromise.

Mandiant documented attackers exploiting misconfigured AD Certificate Services templates to issue certificates and create MFA-exempt impersonator admin accounts. In multiple investigations, attackers dumped entire AD databases, compromising every user credential in the domain. GitGuardian found that 64% of secrets confirmed valid in 2022 remained valid and exploitable in early 2026, representing four years of durable access paths that detection alone has not closed.

Blackpoint’s observation on AiTM phishing is particularly relevant: MFA was never bypassed or broken in the attacks they documented. It worked exactly as designed. The problem is that once MFA succeeds, trust shifts to the session itself, and AiTM attacks are built specifically to steal and reuse that trust. This aligns with the session token defence model covered in my earlier posts on AiTM session token attacks and the case for passkeys.

The non-human identity dimension

A critical nuance from multiple reports is the expansion of the identity problem to non-human identities. Unit 42 noted that service accounts, automation roles, API keys, and emerging AI agents often outnumber human users, are frequently over-privileged, rely on long-lived credentials, and are inconsistently monitored. Wiz found that compromising a service account can be higher leverage and quieter than compromising a person. GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% increase and the largest single-year jump ever recorded. AI service secrets are the fastest-growing leak category, up 81.5% from 2024.

GitGuardian poses three questions every organisation must be able to answer about their non-human identities: what exists in the environment, who owns it, and what can it access. If all three cannot be answered, AI adoption is outpacing security posture.

Defender priority: identity governance as primary security infrastructure

Based on cross-report consensus: phishing-resistant MFA (FIDO2/WebAuthn passkeys) as the minimum standard for privileged roles. Session lifetime reduction for sensitive applications. Conditional access that continuously evaluates device health and risk during active sessions. Just-in-time privileged access replacing standing admin rights. Automated credential revocation and rotation with SLAs measured in hours, not weeks. MFA alone is insufficient when AiTM phishing steals the session token post-authentication; session binding and continuous access evaluation are the necessary additional layers.

3. AI: Accelerant, Attack Surface, and Governance Gap

All 15 reports address AI, making it the most universally discussed topic across the dataset. The findings separate into three distinct dimensions, each with different implications for defenders.

AI as offensive accelerant

CrowdStrike reported an 89% year-over-year increase in AI-enabled adversary activity. Named adversary groups have operationalised AI across social engineering, influence operations, and technical intrusion: FAMOUS CHOLLIMA used GenAI to generate fake personas for fraudulent employment schemes; PUNK SPIDER executes AI-generated scripts during attacks; FANCY BEAR uses LAMEHUG malware implementing AI for discovery and collection. Check Point observed that by 2025, AI use has faded into the background of attack operations, underpinning software development, social engineering, data mining, and post-exploitation without remaining visible in malicious outputs.

Zscaler documented the first credible case of a state-sponsored actor automating 80-90% of an intrusion chain with agentic AI, with human operators intervening only for escalating decisions. Fortian observed ClickFix and infostealer campaigns using AI-generated content to scale social engineering in Australian environments. Check Point documented RENAISSANCE SPIDER using GenAI to translate ClickFix lures into Ukrainian, and Chinese intelligence services using AI to create credible consulting firms targeting former US government employees on job recruitment platforms.

AI as attack surface

Zscaler’s red team testing found critical vulnerabilities in 100% of enterprise AI systems tested, with a median time to first critical failure of just 16 minutes and some systems breached in under one second. Enterprise AI/ML transactions grew 83% year-over-year, approaching one trillion total transactions across approximately 9,000 organisations, with 18,033 terabytes of enterprise data transferred to AI/ML applications in 2025. Engineering teams accounted for 48.9% of all AI usage within organisations.

Check Point and Wiz found that 40% of approximately 10,000 MCP servers reviewed contained security weaknesses. GitGuardian detected 24,008 unique secrets exposed in MCP configuration files in their first full year of mainstream adoption, noting that MCP documentation itself often encourages unsafe patterns by recommending API keys be placed directly in configuration files. The Smithery.ai vulnerability documented by Wiz exposed an overprivileged token granting arbitrary code execution on all 3,000+ hosted MCP servers and access to API keys across hundreds of services, illustrating how centralised AI infrastructure creates catastrophic single points of failure.

GitGuardian found that AI service secrets are the fastest-growing leak category (up 81.5% year-over-year), with 8 of the 10 fastest-growing types of leaked secrets tied to AI services. LLM infrastructure leaks (retrieval APIs, orchestration layers, vector storage) are growing 5x faster than core model providers. Wiz described shadow AI, where employees and teams use AI tools outside formal governance, as creating visibility gaps that security teams cannot address with legacy tooling.

A note on the AI divergence: An important analytical divergence exists across reports on the transformative nature of AI’s current operational impact. Mandiant explicitly states that they do not consider 2025 to be the year where breaches were the direct result of AI, with the vast majority of successful intrusions still stemming from human and systemic failures. Sophos concurs, noting that AI has not delivered a sea change for practical defence, and identifying the structural multi-year rise in identity-related root causes as the more consequential below-the-radar development. CrowdStrike and Zscaler characterise AI’s role as more structurally transformative, emphasising democratised capability and autonomous attack chains.

Both positions are empirically grounded in different observation layers. At the tactical level, AI amplifies existing attack categories rather than creating new ones. At the strategic level, it is changing who can execute what at what cost. The Sophos and Mandiant datasets are weighted toward SME and commercial incident response; CrowdStrike and Zscaler observe nation-state and enterprise-tier activity where AI integration is more operationally mature.

Defender priority: govern AI infrastructure before attackers exploit it

Inventory all AI tools, models, APIs, embedded features, and MCP configurations. Apply secrets management standards to AI infrastructure with the same rigour as any other production system. Never hardcode credentials in MCP configuration files or agent harnesses. Apply adversarial security testing to AI systems, using the Zscaler red team findings as a benchmark for what attackers can achieve. Enterprises blocked 39% of overall AI/ML transactions in 2025 (Zscaler), reflecting growing awareness, but leaving the majority of transactions unsanctioned or unreviewed. The governance gap between AI adoption velocity and security oversight is widening.

4. Ransomware Has Evolved Structurally

Ransomware data across reports consistently reflects a maturing, evolving ecosystem rather than a declining one. Check Point reported 7,960 ransomware victims named on data leak sites in 2025, a 53% year-over-year increase. Q1 2025 recorded 2,289 published victims (134% year-over-year increase), driven substantially by Cl0p’s exploitation of zero-day vulnerabilities. Q4 subsequently surpassed this record with 2,473 victims. In Australia, ASD/ACSC responded to 138 ransomware incidents in FY2024-25, and the mandatory ransomware reporting regime for businesses with annual turnover above $3 million took effect on 30 May 2025.

Three structural shifts are consistent across reports. First, the ecosystem has decentralised into smaller, faster-moving groups resistant to single-point law enforcement disruption. Sophos tracked 51 unique ransomware brands across their cases in 2025. CrowdStrike named 24 new adversaries in the year, bringing the total tracked to 281+. The ransomware ecosystem remained remarkably resilient despite law enforcement disruptions and internal criminal strife.

Second, encryption is declining as a tactic. Unit 42 found that encryption appeared in only 78% of extortion cases, down from over 92% in prior years. Data theft and exposure is now the primary leverage for sophisticated groups that value operational speed and stealth over the operational complexity of encryption. Median ransom demands rose from $1.25M to $1.5M.

Third, backup infrastructure is now a primary pre-encryption target. Mandiant documented ransomware operators shifting their primary objective from data theft to deliberate recovery denial: systematically targeting backup infrastructure, identity services (Active Directory Certificate Services), and virtualisation management planes, destroying the ability to recover and forcing ransom payment. Check Point reconstructed a documented Qilin attack on a European electric utility where the backup server was tampered with on 9 September, with Qilin deployed at 00:20 on 10 September. The attack was not detected until employees arrived at 08:20.

Sophos found that 49.77% of ransomware cases included confirmed data exfiltration (53.92% including potential exfiltration). In most cases where exfiltration was uncertain, a lack of firewall logs contributed to the uncertainty, highlighting telemetry gaps as a root cause of incomplete incident scoping. 84.47% of data exfiltration cases had no defined threat actor attribution, as actors quietly entered, exfiltrated, and exited without identifying themselves.

PRESSURE CHOLLIMA (North Korea), tracked by CrowdStrike, stole $1.46 billion USD in cryptocurrency via a supply chain compromise of Safe{Wallet}, the largest single financial theft ever reported. Blackpoint observed that RMM (Remote Monitoring and Management) tool abuse made up 30.3% of all identifiable incidents their SOC triaged in 2025, with attackers installing rogue RMM tools alongside legitimate ones to exploit the trusted status of the software category.

Defender priority: rebuild ransomware response for 2025 threat realities

Backup infrastructure must be protected as a Tier-0 asset, architecturally separated from production. Organisations must have a data theft extortion response plan that does not assume encryption has occurred. Tabletop exercises should test scenarios where identity services, virtualisation management, and backup infrastructure have all been compromised simultaneously. The Ivanti finding that only 30% of organisations describe themselves as “very prepared” for ransomware, despite 63% rating it as a high or critical threat, quantifies the gap between perception and readiness.

5. The Governance Gap: Deployed Does Not Mean Functioning

A theme cutting across endpoint, identity, AI, and credential domains is the gap between perceived and actual security posture. The evidence from multiple independent sources suggests this gap is systemic and widening.

Absolute Security’s firmware-level telemetry found that approximately 20% of enterprise endpoints are outside a fully protected state at any given time, despite tools being deployed and licensed. Devices spend an average of 76 days per year outside a protected state. The overall share of endpoints in a fully protected and enforceable state improved by only one percentage point year-over-year. One endpoint management vendor saw protected-state integrity drop from 64% to 55% year-over-year without any change in security tool investment. Absolute Security describes this as the “Downtime Era”: the most significant impact of cyber incidents is no longer the breach itself, but the operational disruption that follows.

Ivanti surveyed 1,215 cybersecurity professionals and found a structural preparedness gap: 63% of organisations rate ransomware as a high or critical threat, but only 30% describe themselves as “very prepared” to defend against it. One in four organisations is experiencing a critical cybersecurity skills shortage. 42% identify lack of skilled talent as the primary barrier to cybersecurity excellence, a structural constraint that compounds every other preparedness deficit.

ASD/ACSC data reveals a detection gap in Australian environments: 37% of all significant incidents were discovered via proactive ASD notification rather than by the organisation’s own security systems. ASD proactively notified critical infrastructure entities more than 190 times in FY2024-25, up 111% from the prior year, indicating both growing proactive capability from ASD and the degree to which Australian organisations cannot self-detect sophisticated intrusions.

GitGuardian’s credential data illustrates the remediation gap: detection has occurred for millions of exposed secrets, but remediation has not followed. 64% of credentials exposed in 2022 remain valid in 2026. Until revocation and rotation become routine and automated, a leaked secret is not a short-lived mistake but a durable access path. Zscaler found that many organisations lack a basic inventory of active AI models and embedded AI features, making governance impossible by definition.

Defender priority: continuous control validation

Implement continuous assessment of whether security controls are actually functioning, not just installed. Include endpoint health metrics (percentage of endpoints in protected state, percentage recoverable remotely, mean time to recover) in board-level security reporting alongside traditional coverage metrics. Address the talent constraint as an operational risk: introduce automation for triage and response tasks, distribute workload across engineering functions, and monitor fatigue. Ivanti’s best-in-class organisations (Level 4) share three characteristics: significant investment in exposure management, leadership fully invested in effective cybersecurity, and operationalised AI and automation as defence multipliers rather than experimental capabilities.

Kinetic IT, analysing the Australian regulatory environment, notes that by the end of 2026, breaches caused by blatant negligence, such as ignoring critical patches, will face zero tolerance from regulators and partners. The Cyber Security Act 2024’s “limited use” provision, which ensures information voluntarily shared with ASD/ACSC cannot be used against the reporting organisation in regulatory proceedings, removes a key barrier to proactive engagement with national threat intelligence. Australian organisations should treat this as an opportunity to close the detection gap identified in the ASD data.

What to Do First

The five themes above converge into four immediate priorities with the strongest cross-report consensus and the highest practical impact.

• Priority 1: Deploy phishing-resistant MFA on all privileged accounts and enforce session token binding. This addresses the identity theme directly and is the single control with the most consistent support across all five independent IR datasets. Sophos’s 59.46% MFA gap, Blackpoint’s AiTM session theft findings, and Mandiant’s AD Certificate Services exploitation cases all point to the same conclusion: standard MFA is necessary but insufficient, and session-layer defences must accompany it.

• Priority 2: Extend detection and response coverage to 24/7 across all attack surfaces. The temporal data from Sophos (37.1% of attacks between 11pm and 3am) and the multi-surface data from Unit 42 (87% of intrusions across multiple surfaces) both indicate that daytime-only, endpoint-only coverage creates exploitable gaps. Build automated containment that can activate within minutes for the fastest attack timelines documented by CrowdStrike (29-minute breakout) and Mandiant (under-30-second handoff).

• Priority 3: Inventory and govern AI infrastructure. The gap between AI adoption velocity and security oversight is the fastest-widening governance gap identified across reports. Start with a complete inventory of AI tools, models, APIs, embedded features, and MCP configurations. Apply secrets management standards. Test AI systems under adversarial conditions. Zscaler’s finding that 100% of tested systems failed, combined with 40% of MCP servers containing weaknesses (Check Point/Wiz) and 24,008 secrets in MCP configurations (GitGuardian), establishes the current baseline.

• Priority 4: Test ransomware response plans against the current threat model. If the current plan assumes the attacker encrypted files and the backups are intact, it does not reflect the 2025 threat data. Test for data theft without encryption (22% of extortion cases, Unit 42). Test for backup infrastructure targeted before encryption (Mandiant). Test for identity services compromised simultaneously (Mandiant, Sophos). Test for multiple attack surfaces engaged in parallel (Unit 42). Test for off-hours execution (Sophos).

Footnote: This post is based on a cross-vendor meta-analysis of 15 primary-source threat intelligence reports covering 2025 observations, compiled April 2026. All statistics and characterisations reflect the language and findings of the original publications.

References:

• CrowdStrike: 2026 Global Threat Report

• Mandiant / Google Cloud: M-Trends 2026

• Palo Alto Networks (Unit 42): 2026 Global Incident Response Report

• Sophos: 2026 Active Adversary Report (Nowhere, man)

• Check Point: Cyber Security Report 2026

• Zscaler ThreatLabz: 2026 AI Security Report

• Wiz Research: 2026 Cloud Threats Retrospective

• GitGuardian: 2026 State of Secrets Sprawl

• Fortian: 2025 Cyber Threats: A Frontline Perspective

• ASD / ACSC: Annual Cyber Threat Report 2024–25

• Kinetic IT: 2026 Australian Cyber Security Outlook

• Absolute Security: 2026 Resilience Risk Index

• Ivanti: 2026 State of Cybersecurity: Bridging the Divide

• Blackpoint Cyber: 2026 Annual Threat Report

• CyberCX: 2026 Cyber Threat Report

Part 2 of this series provided a reference architecture for workforce identity, built around managed devices, enforceable authentication policies, and HR-driven lifecycle management. This post covers the customer side, where none of those assumptions hold. The user population is unknown until it self-registers. Devices are unmanaged. Authentication policy must balance security against conversion and retention. And the regulatory obligations around data collection, consent, and deletion apply differently than they do for employee data.

The primary reference platform is Microsoft Entra External ID, which replaced Azure AD B2C for new deployments as of May 2025. Where patterns differ meaningfully in Auth0 (Okta Customer Identity Cloud) and AWS Cognito, those differences are noted. The architecture is organised into seven layers, reflecting the additional complexity that privacy, consent, and fraud introduce in the customer domain.

Layer 1: Tenant and Directory Configuration

Tenant separation

Customer identities belong in a dedicated tenant, separate from the workforce directory. In Entra, this means creating an external tenant, which is a distinct Entra ID instance configured specifically for customer-facing scenarios. This separation keeps customer personal information out of the workforce directory, allows different data residency and retention policies for each population, and avoids licensing conflicts (Entra External ID uses a monthly active user billing model, while workforce Entra ID uses per-user licensing).

In Auth0, the equivalent separation is achieved through a dedicated Auth0 tenant for customer authentication, with the workforce using a separate Okta Workforce Identity Cloud instance or Entra ID. In Cognito, customer identities live in a User Pool, which is inherently separate from any workforce IAM configuration.

Directory schema and progressive profiling

Workforce directories have rich, pre-populated attribute schemas driven by HR data. Every user record includes job title, department, manager, office location, and group memberships, all provisioned before the user’s first login. Customer directories are the opposite. At registration, you may have nothing more than an email address and a consent record. The profile fills in over time as the customer engages with the application.

In Entra External ID, custom user attributes are defined at the tenant level and assigned to sign-up user flows. Built-in attributes cover the basics (display name, email, city, country). Custom attributes extend the schema for application-specific data (loyalty tier, account type, consent version). These are stored as directory extension attributes on the user object and are accessible via Microsoft Graph.

In Auth0, user data is split between two metadata stores: user_metadata (data the user can edit, such as display preferences) and app_metadata (data controlled by the application, such as subscription tier or internal flags). Progressive profiling is implemented through Auth0 Actions, which are JavaScript functions that execute at specific points in the authentication flow. A post-login Action can check whether required attributes are missing and redirect the user to a form that collects them, storing the results in the user’s metadata on completion.

In Cognito, custom attributes are defined on the User Pool at creation time (up to 50 custom attributes). Once defined, custom attributes cannot be removed, which makes schema planning important upfront.

The guiding principle across all platforms is to collect only what is needed at registration and defer additional data collection to later interactions. This reduces registration abandonment, supports data minimisation requirements under privacy regulations, and produces higher-quality data because the customer provides information at the point where it is contextually relevant rather than as part of a long initial form.

Data residency

Where customer identity data is stored geographically matters for regulatory compliance. Entra External ID stores data in the region selected at tenant creation (options include Australia, Europe, the United States, and Asia-Pacific). Auth0 offers regional deployments (US, EU, AU, and JP). Cognito stores data in the AWS region where the User Pool is created. For organisations subject to data localisation requirements or cross-border transfer restrictions (GDPR Article 46, Australian Privacy Principles APP 8, or sector-specific rules), the choice of region at provisioning time is a design decision that is difficult to change later.

Layer 2: Registration and Onboarding

Registration is the customer identity equivalent of workforce provisioning, with one critical difference: the user drives it, not IT. The design of the registration flow directly affects conversion rates, data quality, and the security posture of the account from its first moment.

Self-service registration flows

In Entra External ID, registration is configured through user flows that define the sign-up steps, the attributes collected, the identity providers available, and the page layout (including branding, field ordering, and required/optional field configuration). User flows can be customised with custom authentication extensions, which are API endpoints called during the authentication process that can validate input, enrich the user profile, or enforce business logic.

In Auth0, registration flows are controlled through the Universal Login experience, with customisation via Auth0 Actions (for logic) and Auth0 Forms (for custom UI within the login flow). Actions execute at specific triggers (pre-registration, post-registration, post-login) and can modify user data, call external APIs, or redirect the user to additional forms.

In Cognito, registration is configured on the User Pool with Lambda triggers that fire at specific lifecycle events (pre sign-up, post confirmation, pre token generation). These triggers provide the equivalent extensibility but require writing and hosting Lambda functions.

Social identity provider integration

Most customer identity platforms support federation with social identity providers: Google, Apple, Facebook, and Microsoft accounts are the most common. The technical integration is OIDC-based and follows a consistent pattern across platforms, but several practical considerations affect the architecture.

First, the claims returned by each social IdP vary. Google returns email and name. Apple returns email on first login but may not on subsequent logins. Facebook’s available claims depend on which permissions the application requests and Facebook’s current API policies, which change periodically. The platform needs to handle cases where expected claims are not returned.

Second, account linking is a design decision. When a customer registers with an email address and later tries to sign in with a Google account that uses the same email, the platform needs a policy: should it link the two accounts automatically, prompt the user to confirm the link, or treat them as separate accounts? Each option has security implications. Automatic linking is convenient but can enable account takeover if an attacker controls a social account with the target’s email address. Prompting for verification (require the user to authenticate with both methods) is safer but adds friction.

Third, social IdP availability introduces a dependency. If Google’s authentication service has an outage, customers who registered exclusively through Google sign-in cannot access their accounts. The architecture should either support multiple authentication methods per account or provide a recovery path that does not depend on the social IdP.

Bot protection

Registration endpoints are targets for automated abuse: mass account creation, credential stuffing against existing accounts, and enumeration attacks that test whether an email address is registered. The registration flow should include CAPTCHA integration (or equivalent bot detection), rate limiting per IP and per email domain, and email or phone verification before the account is activated. All three platforms support these controls natively or through integration with third-party services.

Layer 3: Authentication

Customer authentication serves the same purpose as workforce authentication (proving the user’s identity) but operates under different constraints. The organisation cannot mandate a specific authentication method, training is not available, and friction in the authentication flow has a direct impact on business metrics.

Passwords

Passwords remain the baseline authentication method for most customer identity deployments. This is not because they are secure (they are not, particularly against credential stuffing) but because they are universally understood and do not require the customer to take any additional setup steps. The platform should enforce reasonable password complexity requirements, check new passwords against known breached credential databases, and implement rate limiting and IP-based blocking to slow automated attacks.

Passkeys for customers

Passkeys (FIDO2/WebAuthn credentials) offer phishing-resistant authentication without requiring a managed device or hardware security key. Platform authenticators built into iOS, Android, macOS, and Windows allow customers to create and use passkeys with a biometric scan. Synced passkeys (via iCloud Keychain or Google Password Manager) provide cross-device availability without the customer needing to understand the underlying technology.

The deployment model for customer passkeys follows a staged adoption path. In the first stage, passkeys are offered as an optional login method alongside passwords. The registration prompt can be shown after a successful password login, during a security settings review, or at the next login after account creation. In the second stage, passkeys become the default authentication method, with password login still available as a fallback. In the third stage, passkeys are required for all access and passwords are retired. Most consumer-facing services are currently in the first or early second stage.

The metrics that indicate readiness to advance to the next stage include: passkey registration rate (what percentage of active users have enrolled a passkey), authentication success rate for passkey logins (should be above 95%), fallback usage rate (how often users who have enrolled a passkey still fall back to password login), and account recovery volume (whether passkey-related recovery requests are manageable). These metrics need to be tracked per platform (iOS, Android, desktop) because adoption rates and success rates vary across operating systems.

Risk-based step-up authentication

In workforce environments, Conditional Access can require MFA on every login because managed devices and hardware keys make re-authentication fast. In customer environments, requiring MFA on every login drives abandonment. The alternative is risk-based step-up: the session runs with a long duration for low-risk actions, and an MFA prompt is triggered only when the risk profile changes or the user attempts a sensitive action.

When to trigger step-up authentication

• New device or location: The user is signing in from a device or IP address not previously associated with their account. Prompt for a second factor (passkey, OTP, or email verification) before granting full session access.

• Sensitive account changes: The user is changing their password, updating their email address or phone number, modifying payment methods, or managing linked social accounts. These actions should require re-authentication regardless of how recently the user logged in.

• High-value transactions: For financial services and e-commerce, transactions above a configurable threshold should trigger step-up. The threshold and the required factor can be tuned based on the user’s history and risk profile.

• Anomalous session behaviour: The user’s session exhibits behaviour inconsistent with their profile: rapid navigation through account settings, bulk data export, or API access patterns that suggest automated tooling rather than human interaction.

In Entra External ID, step-up logic is implemented through custom authentication extensions that evaluate risk signals and conditionally require additional factors. In Auth0, Adaptive MFA evaluates risk based on device, location, and behavioural signals, and can be supplemented with custom Actions that enforce step-up for specific application-level events. In Cognito, step-up is implemented through Lambda triggers that evaluate context and conditionally challenge the user.

SMS and email OTP

SMS and email one-time passwords remain widely used as a second factor in customer identity, particularly in markets where passkey adoption is early or where the user population includes older devices that do not support WebAuthn. They are not phishing-resistant and are vulnerable to SIM-swap and email compromise, but they provide a second factor that is familiar to most users and does not require any setup beyond providing a phone number or email address. The architecture should support them as a transitional measure while tracking the metrics that indicate when they can be replaced by passkeys for a given user segment.

Layer 4: Session Management

Session management in customer identity lacks the controls available in workforce environments. There is no device compliance enforcement, no Token Protection (which requires managed, enrolled devices), and no compliant network policy. The session controls available are limited to token lifetimes, refresh token rotation, and application-level session validation.

Session duration

In workforce environments, session durations can be short because re-authentication is fast on a managed device with Windows Hello or a hardware key. In customer environments, short sessions create friction. A customer who is forced to re-authenticate while browsing a product catalogue or completing a checkout may abandon the interaction.

The design pattern is tiered session duration. Low-risk actions (browsing, viewing order history, reading content) operate within a long-lived session (days or weeks, depending on the application’s risk profile). Sensitive actions (modifying account settings, initiating payments, accessing personal data) require a more recent authentication, either by checking the session’s authentication time or by triggering a step-up prompt. This is implemented at the application layer rather than at the identity provider layer, because the application understands which actions are sensitive in its specific context.

Refresh token rotation

In customer identity, the client device is unmanaged, which means tokens stored on the device are more exposed than in a workforce environment. Refresh token rotation mitigates this by issuing a new refresh token with each access token refresh and invalidating the previous one. If an attacker steals a refresh token and uses it, the legitimate client’s next refresh attempt will fail (because its token has been consumed), which serves as both a detection signal and a containment mechanism.

All three platforms support refresh token rotation. The trade-off is that rotation can cause issues with concurrent requests: if two browser tabs or two devices attempt a token refresh simultaneously using the same refresh token, one will succeed and the other will fail. The platform configuration should account for this by allowing a short grace period (a few seconds) during which the previous token remains valid.

Session revocation

When compromise is detected, the platform needs to be able to invalidate all of a customer’s active sessions. The mechanisms available include revoking all refresh tokens for the user (forcing re-authentication on the next token refresh), invalidating the user’s account (blocking all access until the account is re-enabled), and rotating the signing key for the application (which invalidates all sessions for all users, a last resort). Detection signals that should trigger revocation are covered in Layer 7.

Layer 5: Account Recovery

In workforce identity, a user who loses access can visit the helpdesk, present identification, and receive a Temporary Access Pass or a replacement credential. Customer identity has no equivalent. Recovery must be entirely self-service, and the design of the recovery flow determines both the security of the account and the customer’s ability to regain access after a lost device, forgotten password, or compromised email.

Email-based recovery

The most common pattern is a time-limited, single-use recovery link sent to the customer’s registered email address. This is adequate for low-to-medium value accounts but has an inherent weakness: if the customer’s email account is compromised, the attacker can initiate and complete recovery. For accounts where this risk is not acceptable, the recovery flow should require a second verification step: re-entering a second factor if one was enrolled, answering a device-bound challenge if the customer has a registered passkey on another device, or completing a remote identity verification.

Passkey recovery

A customer who enrolled a passkey on a device they no longer have faces a specific recovery challenge. If the passkey was synced (via iCloud Keychain or Google Password Manager), recovery is handled by the platform’s sync mechanism: the customer signs into their new device with their Apple or Google account, and the passkey is available automatically. If the passkey was device-bound (stored on a hardware key or on a device that was lost or destroyed), the customer needs an alternative recovery path.

The practical pattern is: allow email-based recovery, then require the customer to register a new passkey during the recovery session. This means the customer temporarily falls back to a less secure authentication method (email link) to regain access, then re-enrols with a phishing-resistant method. The alternative, requiring a second hardware key as a backup, works in workforce environments but is not realistic for consumer accounts.

Remote identity verification

For high-value accounts (financial services, government services, healthcare portals), email-based recovery may not provide sufficient assurance. Remote identity verification services (Onfido, Jumio, or government-provided digital identity APIs) can be integrated into the recovery flow to require document verification and liveness checks before granting access. These services add cost per verification (typically $1-5 USD per check) and latency (verification can take minutes rather than seconds), so they are usually reserved for accounts where the value at risk justifies the investment.

Layer 6: Privacy and Consent

Privacy controls are a structural component of customer identity in a way that they are not for workforce identity. Workforce data handling is governed by the employment relationship. Customer data handling requires explicit consent, and that consent must be technically actionable, not just a checkbox.

Consent collection and management

Consent should be captured as a versioned, auditable record. At registration, the customer agrees to a specific version of the privacy policy and terms of service. If the policy changes, the customer needs to be presented with the updated version and given the opportunity to accept or withdraw. The consent record should include: the version of the policy, the timestamp of acceptance, the method of acceptance (checkbox, click-through, API call), and the scope of processing covered by the consent.

In Auth0, consent versioning can be implemented through Auth0 Actions and Forms: a post-login Action checks the customer’s stored consent version against the current version, and if they differ, redirects the customer to a consent form before completing the login flow. In Entra External ID, custom authentication extensions provide equivalent functionality by calling an API endpoint that evaluates consent status and conditionally blocks or modifies the authentication flow.

Data minimisation

Data minimisation is both a regulatory requirement (under GDPR, the Australian Privacy Principles, and most modern privacy frameworks) and a practical security measure: data that is not collected cannot be breached. The architecture should enforce minimisation at two levels. First, the registration flow should collect only the attributes necessary for the account to function. Second, sensitive attributes that are needed for authorisation but not for identity (health data, financial data, personal preferences) should be stored in the application’s own data layer rather than in the identity directory, and retrieved at runtime via API calls using the customer’s authenticated session.

Right to deletion

When a customer requests account deletion, the identity platform needs to cascade that deletion across all downstream systems that received data from the identity platform: CRM, analytics, marketing automation, transactional databases, and support ticket systems. This is a technical orchestration problem. The identity platform can delete its own user record, but it cannot automatically know which other systems hold copies of that customer’s data.

The practical pattern is to maintain a data map that records which systems receive customer identity data, and to build a deletion workflow that calls each system’s deletion API (or flags the record for deletion if the system does not support automated deletion). This workflow should be tested regularly, because new integrations are frequently added without updating the deletion process.

The common tension is with sector-specific retention requirements. A financial services provider may be required to retain customer identification records for years after the relationship ends (for AML/KYC compliance), even while privacy law requires deletion of data no longer needed for its original purpose. These conflicts cannot be resolved at the technology layer. They require explicit policy decisions about what to retain, in what form (full record vs. anonymised record), and for how long, documented and implemented as automated workflows rather than left to ad hoc processes.

Account dormancy

Customer accounts that have been inactive for an extended period present both a security risk (the customer may not notice if the account is compromised) and a data management problem (retaining data for accounts that may never be used again). The architecture should include a dormancy policy that defines: the inactivity threshold (6 months, 12 months, or whatever is appropriate for the application), the notification sequence before action is taken (email at 90 days before disablement, again at 30 days), the action taken (account disablement followed by deletion after a further grace period), and the reinstatement path if the customer returns after their account has been disabled but before it is deleted.

Layer 7: Fraud Detection and Security Monitoring

Customer identity generates far higher volumes of authentication events than workforce identity, and the acceptable responses to suspicious activity are different. Locking a workforce account and requiring the user to contact the helpdesk is a reasonable response to a suspicious sign-in. Locking a customer account for a false positive creates a support burden and may permanently lose the customer.

Credential stuffing

Credential stuffing attacks use lists of username/password pairs from previous breaches to attempt logins at scale. Detection signals include: high-volume login failures from distributed IP addresses, login attempts using known breached credential pairs, and abnormal geographic distribution of login attempts. Response mechanisms should escalate progressively: CAPTCHA on the next attempt, temporary IP-based throttling, and account notification if a valid credential pair is used from an unrecognised device. Avoid hard lockouts on customer accounts unless there is strong evidence of compromise, because attackers can weaponise lockout policies to deny legitimate customers access to their own accounts.

Account takeover detection

Post-authentication indicators that an account has been compromised include: a new device being added immediately after a password reset, rapid changes to account settings (email, phone, password in quick succession), session activity from a geography inconsistent with the customer’s profile, and transaction patterns that deviate from the customer’s history. These signals should feed into a risk scoring system that can trigger step-up re-authentication, session termination, or account freeze depending on the severity.

Bot detection

Beyond credential stuffing, registration and authentication endpoints are targeted by bots for account creation abuse (creating accounts to exploit promotional offers or conduct fraud), enumeration attacks (testing whether email addresses are registered), and token harvesting. Bot detection can be implemented through CAPTCHA (with progressive escalation based on risk score), device fingerprinting, and behavioural analysis of interaction patterns (typing speed, mouse movement, navigation patterns).

SIEM integration

Customer identity authentication events should feed into the same SIEM as workforce identity events, enabling correlation across both systems. However, the alert thresholds and response playbooks need to be different. Customer identity systems may process millions of authentication events per day, and the false-positive tolerance for automated responses (CAPTCHA escalation, account lockout) is lower because each false positive affects a customer relationship rather than an employee who can be directed to the helpdesk. The SIEM integration should focus on aggregate pattern detection (credential stuffing campaigns, bot activity spikes) and targeted alerts for individual accounts that show strong indicators of compromise, rather than alerting on every anomalous login.

Connecting Customer Identity to the Workforce Architecture

Although the two identity systems are architecturally separate, they connect at three points that the architecture needs to handle cleanly.

First, workforce users who administer the customer identity platform (support agents, product managers, compliance officers) should authenticate through the workforce identity provider and access the customer identity platform through role-based access controls with audit logging. The customer identity system should not maintain separate administrative credentials for internal staff.

Second, B2B scenarios where a business customer’s employees need access to the application are handled through federation between the customer identity platform and the business customer’s workforce identity provider (SAML or OIDC). This allows enterprise employees to authenticate using their corporate credentials while the customer identity platform manages the session and authorisation.

Third, security monitoring should correlate events across both systems. An attacker who compromises a workforce account may attempt to access customer data through the customer identity platform’s administrative interface. Detecting that pattern requires visibility into authentication events from both tiers in the same SIEM.

Architecture Summary

The seven layers described in this post form a customer identity architecture that accounts for the constraints absent in workforce environments: unmanaged devices, self-service registration, voluntary authentication, and regulatory obligations around consent and data handling. The tenant and directory layer provides the structural separation from workforce identity. Registration and onboarding handle the self-service entry point. Authentication balances security against usability through staged passkey adoption and risk-based step-up. Session management compensates for the absence of device trust controls. Account recovery provides self-service paths for customers who lose access. Privacy and consent controls implement the regulatory obligations that apply specifically to customer data. Fraud detection addresses the higher-volume, higher-noise threat environment of customer-facing applications.

Identity Architecture for the Modern Enterprise:

A five-part series covering workforce and customer identity architecture, phishing-resistant MFA, and identity governance.

• Part 1: Why Two Architectures

• Part 2: Workforce Reference Architecture

• Part 3: Customer Reference Architecture

• Part 4: Non-Human Identities in the Workforce

• Part 5: Workforce Identity Governance

The concept of a "Mythos-ready" security programme originates from The AI Vulnerability Storm: Building a Mythos-ready Security Program, published April 2026 by the Cloud Security Alliance CISO Community, SANS, [un]prompted, the OWASP Gen AI Security Project, and the wider community. That paper covers a broad security programme transformation. This post focuses specifically on the vulnerability management implications, drawing on internal enterprise risk analysis of how AI-driven vulnerability acceleration is reshaping defender requirements.

Vulnerability management as it has been practised for the last two decades was designed for a particular environment. Vulnerabilities were discovered at human pace, by researchers working manually or through static scanning tools with known pattern libraries. Exploit development required weeks or months of skilled work. Patch cycles were measured in monthly release windows, and the time between a vulnerability being disclosed and a working exploit appearing in the wild was usually measured in days to weeks, sometimes longer.

That environment no longer exists. AI-assisted vulnerability discovery and exploit development have altered the balance between offensive and defensive cyber capabilities. AI systems can identify defects, generate exploits, and orchestrate attack chains with minimal human intervention. The biggest shift is in the shrinking of the exploit timeline. The interval between vulnerability discovery and exploitation has reduced significantly, in some cases to hours (See Zero Day Clock). Defensive processes such as patching, validation, and change control remain constrained by operational and governance requirements.

This leaves defenders fighting a losing battle against the clock. Attackers benefit from automation and scale, while we must manage complexity, business risk, and system stability. Updating the vulnerability management process is not about adding a new tool to the existing workflow. It is about recognising that several of the assumptions underpinning that workflow are no longer valid.

The Structural Imbalance

The asymmetry between offence and defence in vulnerability management has always existed, but AI has widened it. AI reduces the effort required to discover and exploit vulnerabilities. Techniques that previously required specialised expertise are now accessible at scale. Exploit development increasingly follows vulnerability disclosure or patch release. Reverse engineering of fixes becomes faster, reducing the effective remediation window.

On the defensive side, the constraints have not changed. Patching a production system requires identifying the affected assets, assessing the impact of the patch on application behaviour, testing in a staging environment, scheduling the change window, executing the deployment, and validating that the patch has not introduced regressions. In regulated environments, each of these steps has governance requirements. In operational technology environments, patching may require physical access or planned downtime. None of these constraints respond to the fact that the exploit timeline has shortened.

The result is persistent exposure across systems where patching is delayed or infeasible. That exposure window, which was once a manageable risk accepted within the context of a monthly or quarterly patch cycle, is now a window that an automated attacker can discover and exploit within hours of the vulnerability becoming known.

Where Traditional Vulnerability Management Breaks Down

Four specific assumptions built into traditional vulnerability management are no longer reliable. Understanding where these assumptions fail is necessary before the process can be updated to account for the new environment.

Failed assumptions

• Volume and cadence are manageable: Traditional vulnerability management assumes manageable volumes of disclosures and prioritisation based on severity scoring and threat intelligence. AI-driven discovery increases both the number and frequency of vulnerabilities. This creates sustained pressure on triage, prioritisation, and remediation workflows. Backlogs accumulate. Prioritisation becomes less effective under volume. Organisations rely more heavily on compensating controls, but those controls are often applied ad hoc rather than as part of a deliberate process.

• Detection and response can operate at human speed: Attack execution timelines now operate at machine speed. Detection and response functions often remain dependent on human triage and approval processes. This creates a gap between compromise and containment. Multi-stage attacks can progress through reconnaissance, initial access, lateral movement, and data access before defensive actions are executed. The effectiveness of response capabilities becomes a limiting factor in overall security posture.

• Threat intelligence leads exploitation: CVE-based prioritisation assumes that vulnerabilities are catalogued and contextualised before they need to be acted upon. AI-driven discovery outpaces that cataloguing process. When discovery rates increase by an order of magnitude, the intelligence pipeline lags behind the exploitation timeline. Detection that depends on known indicators misses what has not yet been published.

• Risk models reflect actual exposure: Risk models often rely on assumptions regarding exploit timelines, vulnerability rarity, and prioritisation signals. These assumptions are no longer reliable. Reduced time-to-exploit and increased vulnerability volume distort existing metrics. Governance processes built on those metrics may not respond at the required speed. Decision-making delays that were previously acceptable now translate directly into extended exposure.

Updating the Process

The following updates address the specific failure modes described above. They are not a replacement for existing vulnerability management programmes. They are modifications to existing programmes that account for the changed environment.

Continuous vulnerability discovery and remediation

Replace periodic assessments with integrated, automated processes embedded within development and operational workflows. Embed AI-assisted code review and vulnerability scanning in development pipelines. Implement automated dependency scanning and integrate it with remediation workflows. The objective is to move from finding vulnerabilities during scheduled assessments to continuous discovery as code is written, tested, and deployed.

This includes pointing AI capabilities inward at your own code and dependencies. The same technology that enables AI-driven exploit development can be used for defensive vulnerability discovery.

Risk-based, continuous patching

Move toward risk-based, continuous patching models. Reduce reliance on fixed schedules. The traditional monthly or quarterly patch cycle assumes that the vulnerability is not being actively exploited during the window. With time-to-exploit measured in hours, this assumption is unsafe for any externally-exposed or high-value system.

Define emergency pathways for high-risk vulnerabilities that bypass the standard change control cadence. Balance remediation urgency with system stability through compensating controls: apply virtual patching and isolate exposed systems where full patching is delayed. The trade-off between stability risk from patching and exploitation risk from not patching has shifted. Organisations need to re-evaluate their risk tolerance for operational downtime caused by vulnerability remediation.

Compensating controls as a deliberate programme

When patching cannot keep pace with discovery, compensating controls become the primary defence for the affected systems. This is already happening in most organisations, but it is usually treated as an exception rather than a deliberate part of the programme.

Formalise the use of compensating controls such as isolation, filtering, and feature restriction. Track and validate their effectiveness until full remediation is complete. Treat compensating controls as first-class elements of the vulnerability management process with the same documentation, review, and expiry requirements as any other control. A compensating control that is applied, forgotten, and never validated is just a line item in a risk register creating a false sense of coverage.

Asset visibility as a prerequisite

Implement continuous asset discovery and maintain an accurate inventory. Map asset criticality and remove or isolate unused systems. Every other activity in the vulnerability management process depends on knowing what assets exist, what software they run, what dependencies they include, and whether they are exposed to the network.

Without continuously updated inventory, compensating controls have gaps, prioritisation decisions are made on incomplete data, and remediation efforts may miss the systems that matter most. Aggressively retire unneeded or unmaintained functionality. Phase out suppliers that do not comply with updated vulnerability management requirements. Isolate or air-gap systems that cannot be brought up to standard. You cannot patch, segment, or defend what you do not know exists.

Architectural containment

Assume compromise will occur and design systems to limit propagation. Enforce segmentation across systems and environments. Implement least privilege access and restrict outbound connectivity. Reduce standing privileges through time-bound access controls. The objective is to limit the blast radius when exploitation occurs, because the speed of exploitation now exceeds the speed of remediation for a significant proportion of vulnerabilities.

In an environment where patching was the primary defence and compensating controls were the exception, architectural containment was a secondary layer. Today, architectural containment is the primary control that determines whether a single vulnerability compromise becomes a full-environment incident.

Detection oriented toward behaviour

Shift detection toward behavioural analytics and internal telemetry. Supplement external intelligence with proactive scanning and anomaly detection. Implement behavioural detection and real-time telemetry correlation.

Pre-authorise containment actions such as credential revocation and system isolation. Reduce manual approval latency in response workflows. The gap between compromise and containment is where the damage occurs. Every approval step that requires human intervention during an active incident extends that gap. Identify the containment actions that can be safely pre-authorised (isolating a compromised endpoint from the network, revoking a compromised service account’s credentials, blocking a confirmed malicious IP) and automate their execution when detection thresholds are met.

Supply chain visibility

Modern software relies heavily on third-party components and open-source dependencies. AI accelerates the discovery of vulnerabilities across widely used libraries. Attackers can identify and exploit shared dependencies across multiple organisations simultaneously. A single vulnerability in a common library becomes a key that opens many doors at once.

Maintain software inventories and dependency visibility. Continuously monitor for vulnerabilities in third-party and open-source components. Reduce unused components. Enforce vendor patch obligations. Remediation is complicated by transitive dependencies and reliance on upstream maintainers, so visibility into the full dependency tree is necessary to understand where exposure exists and who is responsible for addressing it.

Governance and Risk Model Updates

Operational process changes will stall without corresponding updates to the governance and risk frameworks that govern them. If the risk model still assumes a 30-day remediation window is acceptable for critical vulnerabilities, the operational team remains constrained by outdated parameters.

Update risk models to reflect reduced time-to-exploit. Introduce operational metrics that measure responsiveness and resilience rather than compliance with a fixed schedule. Useful metrics include: mean time from disclosure to remediation, mean time from detection to containment, percentage of critical vulnerabilities remediated within the risk-based SLA, percentage of exposed systems covered by compensating controls while awaiting remediation, and the age and validation status of active compensating controls.

Streamline governance processes to enable timely security decisions, establishing pre-approved pathways for critical actions so that governance does not become a bottleneck that extends exposure.

AI Agents in the Vulnerability Management Process

AI agents and automation tooling are necessary to enable defenders to operate closer to the speed at which attacks now execute. However, they are also a new class of risk. AI agents introduced into scanning, triage, and remediation workflows are privileged entities interacting with code, data, and infrastructure.

The vulnerability management process should treat AI agents with the same rigour applied to any other privileged identity in the environment. Enforce least privilege on agent access, restrict integrations to approved toolchains, and monitor agent activity strictly. Validate third-party components used by agents, enforce governance over agent usage and human override mechanisms. The agents that help defend the environment need to be defended themselves.

The Workforce Dimension

None of the process changes described above are self-executing. They require people to implement, operate, and maintain them, and those people are already under pressure. The volume of vulnerability disclosures and the cognitive load of integrating AI tooling contribute to sustained fatigue, reduced effectiveness, and potential attrition. Loss of experienced personnel introduces additional operational risk at precisely the moment when experienced judgement is most needed.

Treat workforce capacity as a critical dependency. Introduce automation for triage and response tasks to keep the workload within sustainable bounds, not merely to replace headcount. Allocate surge capacity and monitor fatigue as an operational risk. The vulnerability management process is only as effective as the people operating it.

The Shift in Posture

Being ‘Mythos-ready’ isn’t about buying a flashy new tool or service. It is about accepting that our 30-day remediation cycles are an invitation to attackers. The overall shift must be toward a containment and resilience model rather than relying on prevention alone.

AI-driven vulnerability discovery alters the rate and scale at which security risk materialises. The vulnerability management process is no longer primarily about finding and fixing vulnerabilities on a predictable cadence. It is about reducing the time between discovery and remediation where possible, applying compensating controls where remediation is delayed, and architecting the environment so that exploitation has a limited blast radius.

Note: This post draws on the concept of a "Mythos-ready" security programme introduced in The AI Vulnerability Storm: Building a Mythos-ready Security Program (April 2026), published by the Cloud Security Alliance CISO Community, SANS, [un]prompted, and the OWASP Gen AI Security Project. Lead authors: Gadi Evron (Knostic / CSA), Robert T. Lee (SANS Institute), Rich Mogull (CSA).

Part 1 of this series established why workforce and customer identity need separate architectures. This post provides a concrete reference architecture for the workforce side, using Microsoft Entra ID as the primary platform. Where patterns differ meaningfully in Okta Workforce Identity Cloud, those differences are noted.

The architecture is organised into six layers: directory and hybrid identity, device trust and enrolment, authentication, Conditional Access policy, session management, and external collaboration. Each layer builds on the one below it, and the interactions between layers are where most of the design complexity sits. An organisation that deploys phishing-resistant MFA but does not enforce device compliance, for example, leaves the session token exposed to extraction from unmanaged endpoints. The architecture needs to be coherent across all six layers to be effective.

Layer 1: Directory and Hybrid Identity

The directory is the foundation. Every other layer depends on how identities are structured, where they are mastered, and how they synchronise between on-premises and cloud environments.

Tenant structure

Most organisations should operate a single Entra ID tenant for their workforce. A single tenant provides a unified Conditional Access policy set, a single point of administration for identity governance, and consistent audit logging. Multi-tenant configurations are sometimes necessary for organisations with subsidiaries that require regulatory isolation, or following mergers and acquisitions where consolidation is not yet complete. In those cases, cross-tenant synchronisation can automate the lifecycle of B2B collaboration users across tenants, creating and updating accounts as employees join, move, or leave.

Avoid creating separate tenants for non-production environments unless there is a specific compliance requirement. Development and test workloads can typically be isolated using separate subscriptions or resource groups within a single tenant, with Conditional Access policies scoped to production applications.

Hybrid identity with on-premises Active Directory

Organisations with existing on-premises Active Directory need to synchronise identities to Entra ID. Microsoft provides two tools for this: Entra Connect Sync (a self-hosted synchronisation engine) and Entra Cloud Sync (a lightweight, cloud-managed alternative). Entra Connect Sync remains the more capable option for complex environments with multiple forests, filtering requirements, or writeback scenarios. Entra Cloud Sync is suitable for simpler topologies and organisations that want to reduce on-premises infrastructure.

The choice of authentication method for hybrid users is one of the most consequential design decisions. Three options are available.

Hybrid authentication methods

• Password Hash Synchronisation (PHS): Synchronises a hash of the user’s on-premises password hash to Entra ID. Authentication is handled entirely in the cloud with no dependency on on-premises infrastructure. Microsoft recommends PHS as the most resilient option because cloud authentication continues to work even if on-premises connectivity is lost. PHS also enables Entra ID Protection’s leaked credentials detection, which compares synchronised hashes against known breached credential databases.

• Pass-through Authentication (PTA): Authentication requests are forwarded to on-premises agents that validate credentials against Active Directory in real time. Passwords are never stored in the cloud. PTA has a dependency on the availability of on-premises agents and domain controllers; if they are unreachable, cloud authentication fails. PTA is typically chosen by organisations with regulatory or policy constraints that prohibit storing password material outside their on-premises environment.

• Federation (AD FS or third-party IdP): Authentication is handled by an external identity provider, most commonly AD FS. This introduces the most infrastructure dependencies (federation servers, WAP proxies, certificates) and the most operational complexity. Microsoft is actively encouraging migration away from AD FS toward PHS or PTA. Federation remains necessary in some scenarios, such as smart card authentication against on-premises PKI, but for most organisations it is a legacy pattern that should be retired.

Regardless of which authentication method is chosen, Microsoft recommends enabling PHS alongside PTA or federation as a fallback. This provides resilience against on-premises outages and enables leaked credential detection even when PHS is not the primary authentication method.

The Entra Connect server itself should be treated as a Tier 0 asset. It has write access to the cloud directory and, depending on configuration, write-back capability to on-premises AD. Administrative access should be restricted to domain administrators, the server should be hardened following Microsoft’s privileged access guidance, and its logs should be forwarded to the organisation’s SIEM.

Layer 2: Device Trust and Enrolment

Device trust is the control layer that determines whether a token should be issued to a given endpoint. In a workforce architecture, this layer enables the Conditional Access policies that block token issuance to unmanaged or non-compliant devices, which is the most effective defence against AiTM phishing attacks that use proxy infrastructure (as covered in earlier posts in this series).

Three device registration states exist in Entra ID, each providing a different level of trust.

Device registration states

• Entra ID joined: The device is registered directly with Entra ID and has no relationship with on-premises AD. Used for cloud-only environments. The device receives a Primary Refresh Token (PRT) that enables SSO to cloud applications. Device compliance can be enforced via Intune.

• Hybrid Entra ID joined: The device is joined to both on-premises AD and Entra ID. Used in hybrid environments where the device needs access to both on-premises resources (file shares, printers, legacy applications) and cloud services. Configuration requires Entra Connect and a service connection point in the on-premises forest.

• Entra ID registered: A lightweight registration for personal devices (BYOD). The device is associated with the user’s account but is not fully managed. Provides a PRT for SSO but does not satisfy “compliant device” or “hybrid joined” Conditional Access requirements unless additional controls are applied through an MDM enrolment.

The target state for most organisations is that all corporate-owned devices are either Entra ID joined (cloud-only) or hybrid joined (hybrid environments), enrolled in Intune for compliance management, and subject to a Conditional Access policy that requires compliant or hybrid-joined devices for access to corporate applications. BYOD devices should be enrolled in Intune with a MAM (Mobile Application Management) policy at minimum, or routed through a restricted access path such as a virtual desktop or web-based portal with additional session controls.

Layer 3: Authentication

Authentication is the layer where the user proves their identity. The objective in a modern workforce architecture is to move toward phishing-resistant authentication for all users and to eliminate or restrict weaker methods.

Phishing-resistant MFA

The strongest available authentication methods are passkeys (FIDO2 credentials stored on a device’s platform authenticator or in a hardware security key) and certificate-based authentication (CBA) using smart cards or derived credentials. Both are considered phishing-resistant because they use asymmetric cryptography and are bound to specific origins, making them immune to AiTM proxy attacks.

See my earlier blog on this topic:

In Entra ID, passkey support is configured through passkey (FIDO2) authentication method policies. Passkey profiles allow group-based configuration, so different policies can be applied to different user populations. For example, administrators and privileged roles can be required to use hardware security keys with attestation enforcement, while the broader workforce uses platform authenticators (Windows Hello, Touch ID, Face ID) stored on their managed devices.

The critical implementation detail is disabling fallback to weaker methods. If TOTP, SMS, or push notification MFA remains enabled as a fallback, an attacker can select the weaker method during a phishing attack. Conditional Access authentication strength policies should be used to require phishing-resistant methods for all cloud application access, with the only exception being break-glass emergency access accounts (which should use FIDO2 keys stored offline, not passwords).

Windows Hello for Business

For organisations with managed Windows devices, Windows Hello for Business provides phishing-resistant authentication using biometrics or a device-bound PIN, backed by a TPM-protected key pair. The credentials are bound to the device and cannot be extracted or replayed. Windows Hello for Business can function as the primary authentication method for Windows sign-in and SSO to cloud applications, reducing the need for separate hardware security keys for non-privileged users.

Okta considerations

In Okta Workforce Identity Cloud, phishing-resistant authentication is available through Okta FastPass (a device-bound passwordless authenticator built into the Okta Verify app) and through support for FIDO2 WebAuthn roaming and platform authenticators. FastPass provides cross-platform phishing resistance (Windows, macOS, iOS, Android) and can actively detect AiTM phishing proxies by validating the origin of the authentication request. The equivalent of Entra’s authentication strength policies is Okta’s authenticator assurance policies, which can be configured to require phishing-resistant factors for specific applications or user groups.

Layer 4: Conditional Access Policy

Conditional Access is the policy engine that evaluates signals (user identity, device state, location, risk level, application being accessed) and enforces access decisions (grant, block, or require additional controls). It is the layer that ties directory, device, and authentication decisions together into a coherent security posture.

A well-designed Conditional Access policy set typically includes the following baseline policies. These are not exhaustive but represent the minimum for a reasonably secured environment.

Baseline policies

• Require phishing-resistant MFA for all users, all cloud apps. This is the foundational policy. Use an authentication strength that includes only FIDO2 and Windows Hello for Business. Exclude break-glass accounts (which should have their own dedicated policy requiring FIDO2 keys).

• Require compliant or hybrid-joined device for all users, all cloud apps. This blocks token issuance to unmanaged devices, including AiTM proxy servers. For organisations with BYOD populations, a companion policy can grant access from registered devices with additional session restrictions (app-enforced restrictions, limited session duration).

• Block legacy authentication protocols. Legacy protocols (IMAP, POP3, SMTP AUTH, Exchange ActiveSync with basic auth) do not support MFA and are a common attack vector. Block these for all users without exception.

• Require re-authentication for high-risk sign-ins. Integrate Entra ID Protection risk signals. When a sign-in is classified as medium or high risk (unfamiliar location, impossible travel, anomalous token), require interactive phishing-resistant re-authentication.

Privileged access policies

• Require phishing-resistant MFA every time for privileged role activation. Configure sign-in frequency to “every time” for PIM role activations and access to admin portals (Azure portal, Entra admin centre, Microsoft 365 admin centre). This prevents a stolen session token from being used to activate a privileged role.

• Restrict privileged access to compliant devices from named locations. Privileged roles should only be accessible from specific managed workstations and trusted network locations. This limits the attack surface for administrative operations.

Session controls

• Enable Continuous Access Evaluation (CAE). CAE is enabled by default for supported workloads but verify it has not been overridden. Consider enabling Strict Location Enforcement for applications that handle sensitive data.

• Deploy Token Protection. Enable the Token Protection session control to bind PRTs to the device they were issued on. Start in report-only mode to identify compatibility issues, then move to enforcement. Note the current limitation: Token Protection covers native applications only, not browser sessions.

• Configure sign-in frequency for sensitive applications. For applications that handle financial data, HR records, or customer PII, set a sign-in frequency that requires periodic re-authentication (e.g. every 4 or 8 hours) rather than relying on the default token lifetime.

In Okta, the equivalent of Conditional Access is the combination of authentication policies (per-application MFA and factor requirements), global session policies (session duration and re-authentication rules), and network zones (IP-based location restrictions). The conceptual model is similar but the configuration surface is different. Okta’s device trust integration works through Okta Verify device signals, Okta Device Assurance policies, and, for Microsoft-managed devices, through integration with Intune compliance data.

Layer 5: Session Management

Session management is the post-authentication layer that determines how long a token remains valid and under what conditions it should be revoked. This layer was covered in depth in the earlier session token post, but is summarised here for architectural context.

The key controls are:

• Token Protection: Binds the Primary Refresh Token to the device’s cryptographic material. A token replayed from a different device fails proof-of-possession and is rejected. Currently supports native applications on Windows and macOS only.

• Continuous Access Evaluation (CAE): Establishes a near real-time communication channel between Entra ID and resource providers (Exchange Online, SharePoint, Teams). When critical events occur (password reset, account disabled, high risk detected, location policy violation), the resource provider can reject the token immediately rather than waiting for expiry.

• Compliant network (Global Secure Access): Requires that access to cloud applications originates from a network connection verified by Microsoft’s Global Secure Access client. This prevents token replay from outside the organisation’s managed network perimeter, even for tokens that are otherwise valid.

• Sign-in frequency and persistent session controls: Configurable per-application. Controls how often users must re-authenticate and whether browser sessions persist across closure. For sensitive applications, set sign-in frequency to “every time” with phishing-resistant MFA required.

These controls are most effective when layered. A compliant device policy prevents token issuance to untrusted endpoints. Token Protection prevents replay of tokens extracted from a managed device. CAE enables revocation when conditions change after the token was issued. Together, they cover the pre-authentication, post-authentication, and ongoing session evaluation stages.

Layer 6: External Collaboration

Workforce identity does not exist in isolation. Contractors, agency staff, suppliers, auditors, and partner organisation employees all need some form of access to internal resources. How that access is provisioned, controlled, and eventually removed is one of the more operationally complex aspects of workforce identity.

B2B guest accounts

The most common pattern in Entra ID is B2B collaboration, where an external user is invited as a guest in your tenant. The guest authenticates against their home identity provider and receives a user object in your directory with userType = Guest. You can then assign group memberships, application access, and SharePoint site permissions to that guest object.

The operational risk with guest accounts is accumulation. Guests are created for a specific project or engagement, but there is no built-in mechanism that removes them when the engagement ends. Over time, tenants accumulate hundreds or thousands of stale guest accounts with standing access to resources they no longer need. This is a governance problem that requires deliberate lifecycle management.

Mitigation options include access packages with automatic expiry (covered in Part 5), access reviews that periodically recertify guest access (with auto-removal if the reviewer does not respond), and automated stale account detection based on sign-in activity. Entra ID’s sign-in logs can be queried to identify guest accounts that have not authenticated within a defined window (90 or 180 days), and those accounts can be flagged for review or automatic disablement.

Cross-tenant access settings

Cross-tenant access settings provide per-organisation control over inbound and outbound B2B collaboration. For each partner organisation, you can configure whether to trust their MFA claims and device compliance signals, which users and groups are allowed to collaborate, and which applications they can access. This is more granular than the default collaboration settings and allows you to apply different trust levels to different partners.

For close partnerships where bidirectional collaboration is frequent, cross-tenant trust (trusting the partner’s MFA and device compliance) reduces friction by allowing guest users to satisfy your Conditional Access policies using their home tenant’s MFA enrolment and device compliance state. Without cross-tenant trust, guest users must register MFA separately in your tenant, which creates confusion and increases helpdesk load.

Federation with external identity providers

For partners that do not use Entra ID, SAML or OIDC federation can be configured to allow their users to authenticate using their own identity provider. This is common when working with organisations that use Okta, Ping Identity, or other non-Microsoft identity platforms. Federation provides a better user experience than email one-time passcode (the default for guests without a Microsoft account) but introduces a dependency on the partner’s IdP configuration. If the partner rotates their signing certificate or changes their federation metadata without coordination, authentication can break.

Regardless of which collaboration pattern is used, external identities should be subject to Conditional Access policies that are at least as restrictive as those applied to internal users. Guest users should be required to use MFA (either trusted from their home tenant or registered in yours), access should be scoped to specific applications rather than granted broadly, and session durations should be shorter than those for internal users where the security posture of the partner’s environment is not verified.

Privileged Identity Management

Privileged access requires specific treatment in any workforce identity architecture. The principle is simple: no user should have standing administrative access. Instead, privileges should be activated on demand, scoped to a specific task, and automatically deactivated after a defined period.

Privileged Identity Management (PIM) in Entra ID provides just-in-time role activation for both Entra directory roles (Global Administrator, User Administrator, etc.) and Azure resource roles. Activation can require approval from a designated approver, phishing-resistant MFA re-authentication, and a justification. Role assignments can be configured as eligible (the user must activate before using the role) rather than active (the role is permanently assigned), and activation durations can be limited (e.g. 4 or 8 hours).

For organisations that also use SailPoint for identity governance (covered in Part 5), PIM activation events can be integrated into SailPoint’s access certification workflows, providing a single governance view across both native Entra roles and cross-platform entitlements.

Logging and Monitoring

The identity architecture produces several categories of logs that should be forwarded to the organisation’s SIEM for correlation and alerting.

Entra ID sign-in logs capture every authentication event, including the user, device, application, location, risk level, Conditional Access policies evaluated, and the outcome (success, failure, interrupted). Audit logs capture directory changes: user creation and deletion, group membership changes, application assignment changes, Conditional Access policy modifications, and PIM role activations. These logs can be exported to Azure Monitor (Log Analytics), Microsoft Sentinel, or a third-party SIEM via the Entra diagnostic settings.

Key detection scenarios to configure include: sign-ins from impossible travel locations, sign-ins from unfamiliar devices that bypass device compliance (indicating a potential token theft), PIM role activations outside of business hours or without justification, bulk guest account creation, and changes to Conditional Access policies or authentication method configurations. Microsoft Defender XDR provides pre-built detections for many of these scenarios, including AiTM attack detection and automatic attack disruption.

The Entra Connect synchronisation server should also be monitored. Entra Connect Health provides dashboards and alerts for synchronisation errors, and the server’s operating system logs should be forwarded to the SIEM as a Tier 0 asset.

Architecture Summary

The six layers described in this post form a coherent workforce identity architecture when deployed together. The directory layer provides the identity foundation. Device trust establishes the boundary within which tokens can be issued. Authentication ensures the user proves their identity using phishing-resistant methods. Conditional Access ties these signals together into enforceable policy. Session management protects the tokens after they are issued. External collaboration extends the architecture to partners and contractors with appropriate controls.

Part 3 of this series will cover the equivalent architecture for customer identity, where many of these assumptions (managed devices, enforceable MFA, known user population) do not hold, and a different set of design patterns is required.

Identity Architecture for the Modern Enterprise:

A five-part series covering workforce and customer identity architecture, phishing-resistant MFA, and identity governance.

• Part 1: Why Two Architectures

• Part 2: Workforce Reference Architecture

• Part 3: Customer Reference Architecture

• Part 4: Non-Human Identities in the Workforce

• Part 5: Workforce Identity Governance

Workforce identity and customer identity are often discussed as variations of the same discipline. Both involve authentication, authorisation, directory services, and token management. Both rely on protocols like OIDC, SAML, and SCIM. At the vendor level, the same companies often sell products for both: Microsoft offers Entra ID for workforce and Entra External ID for customers, Okta sells Workforce Identity Cloud and Customer Identity Cloud (Auth0), and AWS provides IAM for internal access and Cognito for customer-facing applications.

But the similarities are largely at the protocol layer. Above that layer, the two domains diverge in user population, device trust model, lifecycle management, regulatory exposure, and the way security trades off against usability. Getting the architecture right for each domain requires understanding those divergences in concrete terms, because the decisions you make about directory structure, authentication policy, session management, and data residency depend on which population you are serving.

This post maps those divergences and establishes the framing for the rest of the series, which will provide dedicated reference architectures for each domain (Parts 2 and 3), patterns for non-human identities in the workforce (Part 4), and a detailed treatment of identity governance for workforce (Part 5).

The User Population Problem

The most obvious difference is the nature of the user population. In workforce identity, the set of users is known and bounded. Every identity corresponds to an employee, contractor, or partner whose relationship with the organisation is documented, usually through an HR system or a procurement process. The organisation controls the onboarding process: identities are provisioned by IT, credentials are issued through a managed workflow, and the user’s role and entitlements are determined by their position in the organisation.

In customer identity, the population is unknown until it self-registers. The organisation has no prior relationship with the user. Registration is self-service, credentials are chosen by the user (or inherited from a social identity provider like Google or Apple), and the user’s profile is built progressively over time rather than provisioned in advance. The user population can range from thousands to tens of millions, and usage patterns are unpredictable. A marketing campaign or seasonal event can produce traffic spikes that workforce systems are never designed to handle.

This difference in population characteristics drives different architectural choices at every level. Workforce directories (Active Directory, Entra ID) are optimised for tens of thousands of identities with rich attribute schemas, group memberships, and organisational unit structures. Customer directories need to handle millions of identities with sparse, gradually populated profiles, and they need to do so with sub-second response times during peak registration and login events. Using a workforce directory for customer identities introduces both a scaling problem and, in many jurisdictions, a data handling problem, since customer personal information is now stored in a system that was designed for a different purpose and may be governed by different retention and access policies.

Device Trust and the Authentication Boundary

Workforce identity operates within a trust boundary that extends to the device. In a well-configured environment, the user’s laptop or phone is enrolled in an MDM solution (Intune, Jamf, VMware Workspace ONE), registered with the identity provider, and subject to Conditional Access policies that evaluate device compliance before issuing tokens. The organisation controls the endpoint: it can enforce encryption, require specific OS versions, deploy endpoint detection and response agents, and bind authentication tokens to the device’s cryptographic material. This device trust model is what makes controls like Token Protection and compliant device Conditional Access policies viable as noted in Part 2 of the Passkeys & Session Security series.

Customer identity has no equivalent trust boundary. The customer authenticates from a personal phone, a shared family computer, a work laptop, or a public terminal. The organisation cannot require MDM enrolment, cannot verify device compliance, and cannot bind tokens to a managed device. Authentication policy has to work with whatever device the customer happens to be using, which means the entire Conditional Access framework that underpins workforce session security (compliant device requirements, Token Protection, managed device attestation) is unavailable.

This has practical consequences for session management. In workforce environments, you can enforce short session durations and frequent re-authentication for sensitive operations because the user is on a managed device and authentication is fast (a biometric scan or a tap on a hardware key). In customer environments, forcing re-authentication creates friction that directly affects conversion and retention. A customer who is asked to re-authenticate while completing a purchase may abandon the transaction. The equivalent control in customer identity is risk-based step-up authentication: the session runs with a long duration for low-risk actions (browsing, viewing order history) and triggers an MFA prompt only when the user attempts something sensitive (changing a payment method, initiating a transfer, updating account credentials).

Identity Lifecycle

The lifecycle of a workforce identity is driven by HR events. An employee is hired, and a provisioning workflow creates their account, assigns group memberships, and grants access to the applications required for their role. The employee changes roles, and an access review or automated workflow adjusts their entitlements. The employee leaves, and a de-provisioning workflow disables their account, revokes their sessions, and archives or deletes their data. This lifecycle can be automated end to end using SCIM provisioning, lifecycle workflows in Entra ID Governance, or an identity governance platform like SailPoint that connects to HR systems like Workday or SAP SuccessFactors.

The customer identity lifecycle has no equivalent driver. Customers self-register, manage their own profiles, and may go dormant for months or years before returning. There is no HR event that triggers de-provisioning. Instead, the organisation needs policies for dormant accounts (when to disable or delete them, and how to notify the customer before doing so), consent withdrawal (how to handle a customer revoking consent for specific data processing), and account deletion on request.

Under the Australian Privacy Principles, organisations are required to take reasonable steps to destroy or de-identify personal information once it is no longer needed for the purpose for which it was collected (APP 11.2). For customer identity systems, this means the platform needs a mechanism to identify accounts that no longer serve their original purpose and either delete or anonymise them. In practice, this obligation often conflicts with other regulatory requirements. A financial services provider subject to AML/KYC record-keeping obligations may be required to retain customer identification data for seven years after the relationship ends, even while the Privacy Act requires destruction of data no longer needed. These conflicts cannot be resolved at the technology layer alone; they require explicit policy decisions about what to retain, in what form, and for how long, and those decisions need to be implemented as automated workflows in the customer identity platform rather than left to manual processes.

Authentication and MFA: Same Goal, Different Constraints

Both workforce and customer identity need strong authentication. Both benefit from phishing-resistant MFA. But the deployment model differs because the organisation’s relationship with the user differs.

In workforce identity, the organisation can mandate authentication methods. It can require passkeys or FIDO2 hardware keys, disable fallback to SMS and TOTP, and issue hardware tokens to every employee. The Essential Eight Maturity Model requires phishing-resistant MFA for workforce access at Maturity Level 2, and for organisations subject to this framework, the deployment decision is not optional. The user experience impact is manageable because the user is an employee who can be trained, issued equipment, and supported by a helpdesk when something goes wrong.

In customer identity, the organisation cannot mandate anything. It can offer passkeys, encourage their use, and make them the default, but it cannot force a customer to enrol. If the authentication flow is too complex or unfamiliar, the customer will abandon it. The Essential Eight’s November 2023 update requires that online customer services offer a phishing-resistant MFA option, but “offer” is not the same as “require.” The practical challenge is building an authentication experience that encourages passkey adoption while maintaining a functional fallback for customers who have not yet enrolled. The FIDO Alliance’s staged adoption model addresses this by defining progressive migration stages, from offering passkeys alongside passwords, to making passkeys the default with password fallback, to eventually requiring passkeys for all access. Most consumer-facing services are still in the first or second stage.

Account recovery further illustrates the gap. A workforce user who loses their security key can walk to the helpdesk, present identification, and receive a Temporary Access Pass or a replacement key. A customer who loses their device cannot. Recovery for customer accounts has to be self-service, which means it needs to be both secure enough to prevent account takeover and simple enough that a legitimate customer can complete it without assistance. Document verification, liveness checks, and email-based recovery flows each carry different trade-offs between security, usability, and cost.

Regulatory Exposure

The regulatory obligations that apply to workforce identity and customer identity overlap in some areas and diverge sharply in others. Understanding where they diverge matters because it affects data architecture decisions, cross-border data flows, and the logging and audit requirements that the identity platform needs to support.

The key takeaway from this regulatory comparison is that workforce identity and customer identity are subject to different compliance requirements, administered by different regulators (the ASD and ACSC for workforce security, the OAIC for privacy), and the identity architecture needs to support both without forcing data or controls from one domain into the other.

Platform Overview

The major identity platforms reflect this architectural separation. The following is not exhaustive but covers the platforms most commonly encountered in enterprise environments.

Workforce Identity Platforms

• Microsoft Entra ID: The most widely deployed workforce identity platform in enterprise environments. Provides directory services, Conditional Access, PIM, and native governance capabilities (access packages, access reviews, lifecycle workflows). Integrates with on-premises Active Directory via Entra Connect for hybrid identity.

• Okta Workforce Identity Cloud : Cloud-native workforce IAM with SSO, adaptive MFA, and lifecycle management. Commonly used in organisations that are not primarily Microsoft-centric or that operate multi-cloud environments.

• SailPoint Identity Security Cloud: Identity governance platform that aggregates identities and entitlements across Entra ID, AD, ServiceNow, SAP, Workday, and legacy systems. Provides role mining, certification campaigns, and separation-of-duties enforcement. Covered in detail in Part 5 of this series.

Customer Identity Platforms

• Microsoft Entra External ID: Microsoft’s customer-facing identity service (formerly Azure AD B2C). Supports custom authentication flows, social identity provider integration, and progressive profiling. Shares underlying infrastructure with Entra ID but uses a separate tenant and configuration model.

• Auth0 (Okta Customer Identity Cloud): Developer-oriented CIAM platform with extensive customisation of authentication flows, social login, and consent management. Widely used in SaaS and e-commerce environments.

• AWS Cognito: AWS-native customer identity service. Provides user pools for authentication and identity pools for authorisation to AWS resources. Commonly used in applications built on AWS infrastructure.

The important point is not which vendor to choose but the recognition that these products exist as separate offerings because the underlying requirements are different. Using a workforce platform for customer identity, or vice versa, introduces misalignment between the platform’s design assumptions and the actual operational requirements. The reference architectures in Parts 2 and 3 will cover how each platform type should be configured for its intended domain.

Where They Connect

Keeping workforce and customer identity architecturally separate does not mean keeping them entirely isolated. There are legitimate connection points between the two domains, and the architecture needs to handle them cleanly.

The most common connection is workforce users who need access to the customer identity system for administration, support, or analytics. A support agent may need to look up a customer’s account, a product manager may need to review authentication metrics, and a compliance officer may need to audit consent records. These workforce users should authenticate through the workforce identity provider and access the customer identity platform through role-based access controls with appropriate logging. The customer identity system should not maintain its own set of administrative credentials for internal staff.

Another connection point is B2B scenarios where a business customer’s employees need access to your services. This sits between the two domains: the users are external (not your employees) but they are part of a known organisation with its own identity provider. Federation (SAML or OIDC) between your customer identity platform and the business customer’s workforce identity provider allows their employees to authenticate using their existing corporate credentials. This is common in SaaS platforms that serve enterprise clients and is typically handled through the customer identity platform’s federation capabilities rather than through the workforce identity system.

A third connection point is reporting and security monitoring. Authentication events from both tiers should feed into the organisation’s SIEM for correlation and analysis. An attacker who compromises a workforce account may attempt to access customer data, and detecting that pattern requires visibility across both identity systems. The logging architecture should allow correlation without co-mingling the identity data itself.

What Follows in This Series

This post has established why workforce and customer identity need separate architectural treatment. The remaining posts in the series will go deeper into each domain.

• Part 2 provides a technical reference architecture for workforce identity, covering directory design, Conditional Access, phishing-resistant MFA, session management, and federation for third-party access, with Entra ID as the primary platform.

• Part 3 does the same for customer identity, covering tenant configuration, authentication flow design, passkey adoption strategy, session management, and privacy compliance, with Entra External ID as the primary platform and comparisons to Auth0 and Cognito.

• Part 4 covers non-human identities in the workforce. These include service accounts, managed identities, API keys, and agent credentials.

• Part 5 covers identity governance for workforce, including access packages, access reviews, and lifecycle automation in both Entra ID Governance and SailPoint.

Part 2 of the Passkeys & Session Security series. See Part 1 here.

In my previous post in this series, we covered why traditional MFA methods are failing against Adversary-in-the-Middle (AiTM) phishing and why passkeys represent the strongest available countermeasure. This post picks up where that analysis left off. Deploying passkeys addresses the credential theft stage of an AiTM attack, but there is a second, equally important problem: what happens to session tokens after authentication succeeds?

Even in environments that use phishing-resistant MFA, session tokens and cookies remain a target. An attacker who obtains a valid session cookie through malware, a compromised browser extension, or a token extraction tool can replay that cookie from their own device and inherit the user’s authenticated session. This class of attack is often referred to as token theft or session hijacking, and it operates independently of how the user originally authenticated.

Microsoft reported a 146% increase in AiTM attacks over the past year, and the post-authentication phase is where attackers are increasingly focusing their effort. Defending against this requires a shift in thinking: from protecting the login process to protecting the session itself.

Why MFA Alone Does Not Protect Session Tokens

To understand the gap, it helps to trace what happens after a successful authentication. When a user logs into a service like Microsoft 365, the identity provider (Entra ID, formerly Azure AD) issues a set of tokens: an access token, a refresh token, and in many cases a Primary Refresh Token (PRT) that enables single sign-on across applications. These tokens are stored on the device, typically in the browser or in the operating system’s credential store.

MFA is evaluated at the point of authentication. Once that check passes and tokens are issued, the MFA layer is no longer involved in subsequent requests. The tokens themselves become the proof of identity. If an attacker can extract or intercept those tokens, they can present them from a different device, and the resource provider (Exchange Online, SharePoint, etc.) will accept them as valid. No further MFA challenge is triggered because the session has already been authenticated.

This is the core problem. Traditional session management assumes that once a token is issued to a trusted user, it will only be used from that user’s device. AiTM phishing proxies, info-stealer malware, and malicious browser extensions all violate that assumption by extracting tokens and delivering them to the attacker in real time.

146% increase in AiTM attacks observed by Microsoft over the past year, with attackers increasingly targeting session tokens rather than credentials alone.

The Defence Layers: Token Binding, Device Compliance, and Continuous Evaluation

Addressing session token theft requires controls at three distinct points: preventing token issuance to untrusted devices, binding tokens to specific devices so they cannot be replayed elsewhere, and continuously evaluating sessions so that compromised tokens can be revoked in near real time. Each layer addresses a different failure mode, and they are most effective when deployed together.

1. Conditional Access: Require Compliant or Managed Devices

The most impactful control is a Conditional Access policy that requires sign-in requests to come from a device that is either Entra-joined, hybrid-joined, or marked as compliant by an MDM solution like Intune. This is a pre-authentication control: it evaluates the device state before a token is issued.

An AiTM phishing proxy cannot satisfy this requirement. The proxy server is not a managed device, does not have a valid device certificate, and cannot present a PRT. When a compliant device policy is enforced, the identity provider refuses to issue tokens to the proxy, and the attack chain breaks at the authentication stage rather than after it. Microsoft’s own documentation confirms that requiring a compliant or hybrid-joined device is an effective mitigation against AiTM phishing because the attacker’s infrastructure cannot present a valid device identity.

For organisations that manage both corporate and BYOD environments, this may require different policy tiers. Corporate devices can be required to be fully compliant, while BYOD devices might be permitted with additional session controls (shorter token lifetimes, restricted application access). The key principle is that no token should be issued to an unmanaged endpoint without compensating controls.

2. Token Protection: Binding Tokens to Devices

Token Protection is a Conditional Access session control in Microsoft Entra ID that cryptographically binds sign-in session tokens to the device they were issued on. When a user registers a supported device with Entra ID, a Primary Refresh Token is issued and bound to that device’s cryptographic material. If an attacker extracts the token and attempts to replay it from a different device, the proof-of-possession check fails and access is denied.

Token Protection addresses a scenario that compliant device policies do not fully cover: token theft from a legitimate, managed device. If an attacker compromises a compliant device through malware or a malicious browser extension and extracts the PRT, a compliant device policy would have already been satisfied at the time of issuance. Token Protection adds a second check by verifying that the token is still being used from the same device it was bound to.

There are limitations to be aware of. As of early 2026, Token Protection in Entra ID supports native applications only (Outlook, Teams, OneDrive via WAM-based authentication). Browser-based session cookies are not yet covered by this control, which is a significant gap given that most AiTM attacks steal browser cookies specifically. Token Protection should be treated as one layer in a defence-in-depth strategy rather than a standalone solution.

3. Continuous Access Evaluation (CAE)

Traditional token-based authentication has a fundamental timing problem. Once an access token is issued, it remains valid until it expires, which can be up to an hour for standard tokens or up to 28 hours for CAE-enabled sessions. If a user’s account is disabled, their password is reset, or their device falls out of compliance during that window, the existing token continues to work.

Continuous Access Evaluation addresses this by establishing a communication channel between the identity provider (Entra ID) and the resource provider (Exchange Online, SharePoint Online, Teams). When a critical security event occurs, such as an account being disabled, a password being changed, MFA being enabled, or a high-risk state being detected by Entra ID Protection, the resource provider is notified in near real time and can reject the token immediately rather than waiting for expiry.

CAE also supports location-based evaluation. If an organisation enforces a Conditional Access policy requiring access from specific IP ranges, and a token is replayed from an IP address outside those ranges, CAE can block the request without waiting for the token to expire. With Strict Location Enforcement enabled, this becomes a near real-time check rather than an opportunistic one.

For Australian organisations aligning with the ASD Essential Eight, CAE supports the maturity model’s requirements around restricting access to managed devices and logging authentication events. The Essential Eight’s November 2023 update requires phishing-resistant MFA at Maturity Level 2 and event log monitoring at higher maturity levels, both of which are complemented by CAE’s near real-time session evaluation and its integration with Entra ID sign-in logs.

Practical Implementation: Where to Start

Deploying these controls in sequence reduces risk incrementally while avoiding disruption to users. The following order reflects a practical rollout path based on impact and complexity.

Enforce compliant device policies for privileged accounts

• Start by creating a Conditional Access policy that requires Entra-joined or compliant devices for all administrator and privileged role sign-ins. This blocks AiTM token issuance for the highest-value accounts.

• Extend to all users once device enrolment is complete across the workforce.

Enable Continuous Access Evaluation

• CAE is enabled by default for tenants with supported Microsoft 365 workloads, but verify it has not been overridden by existing Conditional Access policies.

• Consider enabling Strict Location Enforcement for high-risk applications.

• Test revocation behaviour by disabling a test account and confirming that active sessions are terminated in near real time.

Deploy Token Protection in report-only mode

• Enable the Token Protection session control in report-only mode first to identify which devices and applications are affected. Review sign-in logs for unbound token events.

• Once you have confirmed compatibility across your supported device fleet, move the policy to enforcement.

Tighten session durations for sensitive operations

• Configure sign-in frequency policies to require re-authentication for sensitive operations, such as PIM role activation, access to financial systems, or changes to authentication methods. Setting sign-in frequency to “every time” for these operations, combined with requiring phishing-resistant MFA, prevents a stolen token from being used to complete high-impact actions.

Deploy phishing-resistant MFA across all accounts

• If you have not yet deployed passkeys or FIDO2 hardware keys, this remains the single most effective control against AiTM credential theft. Combine with the session controls above.

• As Cloudflare’s experience demonstrated, disabling fallback to weaker MFA methods (TOTP, push notifications) is critical, because attackers will use whatever fallback path is available.

Monitor and respond to token theft signals

• Deploy Microsoft Defender XDR workloads to detect suspicious sign-in patterns, such as impossible travel, token replay from unfamiliar devices, or duplicate sessions. Configure automated session revocation in response to high-risk detections.

• Review Entra ID sign-in logs for anomalous authentication patterns on a regular cadence.

Known Limitations and Gaps

It is worth being direct about what these controls do not yet cover. Token Protection in Entra ID does not currently protect browser-based sessions, which are the primary target for AiTM phishing kits that steal session cookies from the browser. Until Microsoft extends token binding to browser sessions, organisations should treat browser-based access as a higher-risk channel and apply compensating controls such as location restrictions, shorter session durations, and compliant network requirements via Global Secure Access.

CAE propagation is not instantaneous for all event types. Microsoft notes that policy and group membership changes can take up to a day to propagate, although user-level events like password resets and account disablement are enforced in near real time. Organisations that need immediate enforcement of group-based policy changes should use the Revoke-MgUserSignIn PowerShell cmdlet to manually revoke sessions.

Compliant device policies also introduce friction for organisations with significant BYOD populations or contractors who use unmanaged devices. These users will be blocked from accessing resources unless an alternative access path is configured, such as a virtual desktop environment or a restricted web application with additional session controls. Planning for these edge cases is part of a successful rollout.

The Australian Context

The ASD Annual Cyber Threat Report 2024-25 found that phishing, account compromise, and identity information gathering were the top three observed attack techniques across both government and non-government incident reports. Compromised credentials were involved in 42% of critical incidents. Info-stealer malware, which harvests session cookies and credentials from browsers, was specifically called out as a growing concern.

The Essential Eight Maturity Model now requires phishing-resistant MFA at Maturity Level 2 and mandates event logging that captures authentication events. The session management controls described in this post, particularly CAE, compliant device enforcement, and sign-in log monitoring, align with the Essential Eight’s requirements at Maturity Levels 2 and 3. For Commonwealth agencies subject to the PGPA Act, these are mandatory.

The ASD’s advice to organisations is to operate with a mindset of “assume compromise” and prioritise protecting high-value assets. Session token defence fits directly within that model: rather than relying solely on preventing initial access, these controls limit what an attacker can do with a stolen token and reduce the window of exposure when a compromise does occur.

Resources

Documentation and implementation guides for the controls discussed in this post.

• Microsoft: Protecting Tokens in Entra ID

• Token Protection in Conditional Access

• Continuous Access Evaluation

• ASD Essential Eight Changes

For years, IT administrators and security teams have given the same advice: enable Multi-Factor Authentication to protect your accounts. It was reasonable guidance. Adding a second factor on top of a password raised the cost of a successful attack. But the threats have changed, and that advice alone is no longer sufficient.

That number deserves attention. Attackers are now routinely bypassing SMS codes, authenticator apps, and push notifications, often in real time and at scale. Whether you manage authentication for an enterprise or simply want to keep your personal accounts secure, the picture is clear: traditional MFA is not holding up against modern phishing, and phishing-resistant passkeys are the most effective alternative available.

The Rise of the Adversary-in-the-Middle Attack

The main reason traditional MFA is losing effectiveness is the growth of Adversary-in-the-Middle (AiTM) attacks. Earlier phishing campaigns focused on stealing passwords. Current attacks use Phishing-as-a-Service (PhaaS) platforms, including tools like EvilProxy, Tycoon 2FA, and Evilginx, to position malicious proxy servers between the victim and the legitimate website.

The attack works like this. A user clicks a link in a phishing email and arrives at what looks like a normal Microsoft 365 or Google login page. It is the real login page; the attacker’s proxy is relaying traffic in both directions. The user enters their password. The real site prompts for an MFA code. The proxy passes that prompt along. The user enters the one-time code or taps “Approve” on their phone, as trained.

At that point, the legitimate service authenticates the session and issues a session cookie. The attacker captures it. With that cookie, they can hijack the authenticated session and access the account for as long as the session remains valid, with no need for the password or MFA device again. The Canadian Centre for Cyber Security, which analysed over 100 AiTM campaigns targeting Microsoft Entra ID between 2023 and early 2025, found that phishing-resistant MFA was the only defence that consistently prevented compromise.

These attacks have increased roughly 46% in 2025, largely because PhaaS kits have become commoditised. A low-skilled attacker can rent a turnkey phishing platform, select a template mimicking a major identity provider, and begin harvesting session tokens within hours.

Why SMS, Authenticator Apps, and Push Notifications Fall Short

The reason AiTM works against these MFA methods comes down to one structural weakness: traditional MFA relies on shared secrets.

Every legacy MFA method, whether it sends a code over SMS, generates a time-based one-time password (TOTP) in an authenticator app, or triggers a push notification, ultimately produces a value that gets typed into a browser or approved with a tap. That value is the shared secret. Because it passes through the browser, an AiTM proxy sitting between the user and the real website can capture and replay it in real time.

How each method fails against AiTM

SMS & Email One-Time Passwords

The code is transmitted over an interceptable channel, then typed into the browser, where the proxy captures it immediately. CISA notes that SMS codes are also vulnerable to SIM-swap attacks and SS7 protocol exploits.

Authenticator Apps (TOTP)

Although codes are generated locally on your device, the moment you type the six-digit code into a browser window, the AiTM proxy can intercept and use it within its 30-second validity window. The code is still a shared secret; it just has a shorter lifespan.

Push Notifications

Attackers bypass push-based MFA in two ways: the proxy can intercept the session approval in real time, or the attacker can bombard the user with repeated push requests (a technique called “MFA fatigue” or “push bombing”) until the user accidentally taps “Approve.”

Because all of these methods can be intercepted and replayed by an attacker observing the authentication exchange as it happens, they offer limited protection against modern phishing kits. The security model they were built on no longer accounts for the way attacks actually work.

Phishing-Resistant Passkeys: How They Work

Stopping AiTM attacks requires MFA that cannot be intercepted, replayed, or approved by a confused user. The FIDO2 and WebAuthn standards were designed to meet that requirement. The most widely adopted form of this technology is the passkey.

Passkeys and hardware security keys (like YubiKeys) address the vulnerabilities in traditional MFA at the protocol level. Three properties make them resistant to phishing.

Why Passkeys Can’t Be Phished

1. No Shared Secrets to Steal

Unlike passwords or OTP codes, passkeys use asymmetric public-key cryptography. Your private key is generated and stored inside your device’s tamper-resistant hardware. It does not leave the device, is not transmitted over the network, and is not typed into a browser. Because no secret value flows through the browser, there is nothing for an AiTM proxy to intercept.

2. Cryptographic Origin Binding

This is the most important property. When you attempt to log in, your browser and authenticator automatically verify the website’s actual domain (its “origin”). If an attacker lures you to evil-bank.com instead of real-bank.com, the passkey will refuse to generate a valid cryptographic signature for the fake site. The protocol will not authenticate to a domain the credential was not registered with, regardless of what the user does.

3. Replay Immunity

Every authentication challenge is unique and time-bound. Even if an attacker could somehow record the encrypted traffic of your login, they could never replay it to gain access. Each response is valid only for that specific challenge, that specific origin, at that specific moment.

As Swissbit’s security researchers have noted, because FIDO2/WebAuthn does not send credentials, codes, or session tokens over the network, session hijacking (the core technique behind AiTM attacks) becomes ineffective.

Real-World Results

The case for passkeys and hardware security keys is supported by deployment data from several large organisations that are frequent phishing targets.

Google: Zero Phishing Since 2017

After requiring all 85,000+ employees to use physical security keys, Google reported zero successful phishing attacks on employee work accounts. A FIDO Alliance case study confirmed the results: an internal study showed TOTP-based authentication had an average failure rate of 3%, while U2F security keys had a 0% failure rate.

Cloudflare: Hardware Keys Blocked an Active Attack

In July 2022, Cloudflare was targeted by the same phishing campaign that breached Twilio and hit over 130 companies. Some Cloudflare employees clicked the phishing links and entered their passwords. The attack did not succeed because the company’s FIDO2-compliant hardware security keys could not authenticate to the fraudulent domain.

Microsoft: Passwordless at Scale

Microsoft has been rolling out passkey and FIDO2 support across Microsoft Entra ID, and internally uses Windows Hello and FIDO2 security keys for employee authentication. The company now requires MFA for all Azure and Microsoft 365 admin access, with passkeys recommended as the strongest option.

The Cloudflare case is worth examining closely. The same phishing campaign that compromised Twilio, a company with a capable security team, was stopped by Cloudflare’s hardware keys. The difference was not employee training or awareness. Some Cloudflare employees did fall for the phishing messages. The difference was architectural: FIDO2 keys implement origin binding, so a real-time phishing proxy cannot extract usable authentication material.

Regulators Are Demanding the Switch

Phishing-resistant MFA is also becoming a regulatory expectation. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) strongly urges all organisations to implement phishing-resistant MFA as part of Zero Trust principles. The Office of Management and Budget requires federal agencies to adopt phishing-resistant methods.

In Australia, the Australian Signals Directorate (ASD) updated its Essential Eight Maturity Model in November 2023 to require phishing-resistant MFA at Maturity Level 2, down from the previous Maturity Level 3. This means a much larger number of Australian organisations, including all Commonwealth government agencies subject to the PGPA Act, now need to implement FIDO2 or equivalent phishing-resistant authentication. Weaker methods like SMS codes and standard push notifications no longer satisfy the MFA requirements at this level. The update also removed the option for customers to opt out of MFA on services that store sensitive data, and requires online customer services to offer a phishing-resistant MFA option.

The urgency of this shift is reflected in the numbers. The ASD Annual Cyber Threat Report 2024-25 recorded over 1,200 cyber security incidents (an 11% increase year-on-year) and 84,700 cybercrime reports, roughly one every six minutes. Phishing, account compromise, and identity information gathering were the top three observed attack techniques. Compromised credentials were involved in 42% of critical incidents. The average cost of a cybercrime report for Australian businesses rose 50% to $80,850. The ASD’s own advice to individuals and organisations now explicitly recommends using phishing-resistant MFA wherever possible, preferably passkeys.

NIST guidance is moving in the same direction. Microsoft’s mandatory MFA enforcement for Azure, rolled out in phases through 2025, explicitly recommends passkeys (FIDO2) as the preferred method, particularly for break-glass and emergency access accounts.

The trend is consistent across jurisdictions: legacy MFA is being formally deprecated in favour of phishing-resistant alternatives, and organisations that do not make the transition face growing compliance gaps.

Making the Switch

A common objection to passkeys is deployment complexity, but passkey support is now built into every major platform. Microsoft Entra ID supports passkeys with granular policy controls. Apple syncs passkeys across devices via iCloud Keychain. Google Password Manager handles passkey sync on Android and Chrome. Windows Hello provides on-device biometric authentication using the same FIDO2 protocol.

For organisations, the practical rollout follows a predictable path. Start by enabling passkey support in your identity provider (Entra ID, Okta, Google Workspace). Issue hardware security keys to high-privilege users first: IT administrators, executives, anyone with elevated access. Then expand to the broader workforce using platform authenticators (biometrics built into their laptops and phones). Importantly, disable fallback to weaker MFA methods. As Cloudflare learned, if users can fall back to TOTP or push notifications, so can attackers.

For individual users, the process is simpler still. Most major services, including Google, Microsoft, Apple, GitHub, and Dropbox, already support passkeys. You can create one in your account security settings in under a minute. Once enrolled, logging in requires a biometric scan or a tap on a hardware key, which is faster than typing a password and retrieving an OTP code.

One area where adoption is still lagging is Australian banking. While major Australian banks have signalled their intent to support passkeys, most have not yet rolled out phishing-resistant MFA for consumer accounts. Given that online banking fraud is among the top three cybercrimes reported by individuals in Australia, this gap is worth watching. In the meantime, users should enable passkeys on every service that supports them and use hardware security keys for high-value accounts.

Resources and Next Steps

Passkey support is available across all major platforms and identity providers. These links cover implementation details for both enterprise and individual use.

• CISA Implementation Guide

• ASD Essential Eight Changes

• FIDO Alliance: Passkeys

• Microsoft Entra Passkey Setup

WIMA Cybersecurity 2026 Participant Guide

762KB ∙ PDF file

Download

Download

This Is Not an IT Problem

On 23 November 2022, staff at AIIMS New Delhi arrived for work to find their hospital’s computer systems either crawling or completely unresponsive. By 7:00 AM, the e-Hospital system - the platform that handled registrations, admissions, billing, lab reports, and appointments - was offline.

What followed was not just a technology failure. It was a patient safety crisis. For over two weeks, one of India’s most well-known government hospitals had to run on pen and paper - handwritten prescriptions, physical file management, manual billing - while serving 12,000 patients a day.

This guide starts here, not with the history of firewalls or the mechanics of malware, because this is the reality that matters. When hospital systems go down, the result is not just data loss. It is the operational standstill that holds up patient care.

The AIIMS Attack: What Actually Happened

The National Informatics Centre confirmed that AIIMS had been hit by a ransomware attack - malicious software that scrambles your data and demands payment for the key to unlock it.

• Five of the hospital’s 100 physical servers were directly breached.

• About 1.3 terabytes of data were encrypted and made inaccessible.

• Around 40 million patient records were potentially exposed, including records of senior politicians, judges, and bureaucrats.

• The attackers, later named as the LockBit ransomware gang, reportedly demanded around ₹200 crore (roughly USD 24.5 million) in cryptocurrency.

The hospital went fully manual for over two weeks. Patients who had travelled from rural areas for scheduled surgeries arrived to find no record of their appointments. Emergency triage ran on handwritten notes. Blood bank records were inaccessible, holding up transfusions. The Delhi Police registered a case of extortion and cyber terrorism, and five separate agencies - CERT-In, CBI, NIA, Intelligence Bureau, and the Ministry of Home Affairs - got involved.

A later report by Sentinel Labs and Recorded Future named the attackers as ChamelGang, a group with suspected links to China, using ransomware called “CatB.” The report suggested the ransomware may have been partly a cover for espionage.

The Lesson Every failure at AIIMS was preventable. Not one of the fixes required expensive technology. They required preparation: an incident response plan, offline backups, network segmentation, and staff training.

Clinical Continuity: What to Have Ready Before an Attack

The question every medical superintendent, nursing director, and department head should be asking is: “When the systems go down at 3am, what do my staff do in the first 60 minutes?”

Paper fallback systems

Pre-printed registration forms, prescription pads, and discharge summaries need to be stored in every department - not in one central store that might be inaccessible during an attack. Think of it like crash carts: you don’t keep one for the whole hospital.

Critical data kept offline

The last 48 hours of ICU charts, medication schedules, and ventilator settings should be printed daily. If you build this into the shift handover process, the same printout that works as a handover tool also works as a backup.

Crisis communication

When your hospital email goes down, your VoIP phones may go down too - they run on the same network. Pre-configured WhatsApp groups (one for senior clinical leadership, one per department) may be the only communication channel that still works, because they run on personal mobile networks, not on the hospital’s compromised systems.

The WhatsApp Paradox During normal operations, this guide tells you to be careful with patient data on WhatsApp. But during a cyberattack, WhatsApp may be your only working communication channel. Set up crisis groups now. Test them regularly.

Trained staff

Run annual “digital downtime” drills - pick a department, switch off the screens for a shift, and practise paper-based operations. You will find gaps you never knew existed. Reception staff need specific training on manual registration. Pharmacy needs printed formulary access. Lab needs manual sample-tracking workflows.

The first 60 minutes

• Clinical leader in charge - not just the IT head, because the key decisions are about patient triage, not server recovery.

• Triage systems by clinical priority - life-support first, then diagnostics, then admin. The billing system can wait. The ICU ventilator network cannot.

• Switch to manual workflows immediately. Don’t wait to see if systems come back.

• Ambulance diversion - if your ED can’t function safely, you need pre-arranged agreements with neighbouring hospitals and a clear protocol for who authorises the diversion.

Recovery

Don’t rush to reconnect. Systems that haven’t been fully cleaned can trigger a second wave of encryption. Restore from verified backups, starting with the most critical clinical systems. Every handwritten entry during the downtime needs to go back into the restored digital system - tedious but essential for continuity of care records.

Why Healthcare Is the Number One Target

According to the India Cyber Threat Report 2025, the healthcare sector accounted for about 21.82% of all detected cyber threats in India in 2024 - more than banking, more than IT, more than any other sector.

Why?

• High-value data. A single patient record is worth roughly ₹21,000 on the dark web. A credit card number fetches ₹420-840. The difference: a credit card can be cancelled with one phone call. Your blood type, surgical history, and Aadhaar-linked insurance details cannot be changed.

• Life-or-death urgency. Attackers know hospitals will pay ransoms quickly because the alternative is patients going without care.

• Expanding attack surface. Every connected device - heart monitors, infusion pumps, MRI machines - is a potential way in. Many of these devices run outdated software and were never built with security in mind.

• Legacy systems and thin resources. Many Indian hospitals run on old operating systems that no longer get security updates. Most small to mid-size hospitals have no dedicated security team at all.

Indian Healthcare Case Studies

Regional Cancer Centre, Thiruvananthapuram (April 2024)

The Daixin Team targeted 11 of 14 servers at Kerala’s premier cancer treatment centre on 30 April 2024. Around 20 lakh patient records were exposed. The software controlling linear accelerators - the machines that deliver radiation doses to cancer patients - was directly attacked, forcing a temporary halt to radiotherapy planning. The attackers demanded a ransom reportedly in the range of USD 100 million (roughly ₹840 crore).

This was the first major Indian attack to go after life-saving treatment equipment directly. Previous attacks disrupted records and admin. This one disrupted cancer treatment.

Safdarjung Hospital, New Delhi (November 2022)

Hit in the same month as AIIMS, Safdarjung - a 1,500-bed central government hospital - had its servers knocked down for a day. The Medical Superintendent confirmed it was a cyberattack but not ransomware. During the same period, the ICMR website faced about 6,000 hacking attempts in 24 hours. Three major medical institutions hit in one month. This was coordinated, not random.

Safdarjung’s OPD services were less affected because they were already running manually - an accidental insurance policy. But relying on being “too analogue to hack” is not a security strategy.

MGM Hospital, Navi Mumbai (July 2018)

A receptionist at MGM Hospital in Vashi switched on her computer one Sunday morning to find a blank screen. By the time anyone reacted, every terminal on the network was infected. Fifteen days of billing and patient data were encrypted. The attackers demanded Bitcoin.

At the time, India had the highest ransomware infection rate in the world - 67% of organisations hit in 2017, according to Sophos. The entry point was almost certainly a staff member clicking a link in a phishing email.

71 Hospitals Breached via a Shared Diagnostic Platform (2022-2023)

A breach in a shared cloud-based Laboratory Information Management System (LIMS) gave attackers access to 71 hospitals and over 1,000 diagnostic centres. The platform synced test results, insurance claims, and billing. Attackers exploited a vulnerability in the platform’s API, and because all 71 hospitals shared the same insecure API tokens with no network segmentation, one breach opened a backdoor to every connected facility.

Over 1.5 terabytes of data were exposed, including medical scans, insurance details, and doctor’s notes. Several hospitals had to disconnect and revert to paper for weeks.

This put paid to the idea that “cloud integration” is automatically more secure. In any connected system, the weakest link sets the security level for everyone.

Sree Chitra Tirunal Institute, Kerala (Recurring Threats)

The Sree Chitra Tirunal Institute - an Institution of National Importance developing indigenous medical devices like the Chitra Heart Valve and neuro-prosthetics - has faced repeated spear-phishing campaigns. Attackers sent emails to senior cardiac surgeons disguised as official communications from the Ministry of Health or international journals.

They weren’t after patient phone numbers. They were after the proprietary design data and alloy compositions of implants worth millions on the black market. In 2023, credential harvesting led to the temporary exposure of treatment protocols for rare neurological disorders - work built up over decades of specialist clinical research.

For institutes like SCTIMST, the risk is not just data privacy. It is about protecting India’s indigenous medical R&D.

The Digital Sterile Technique

In clinical practice, sterile technique is not optional. You don’t skip handwashing because you’re in a hurry. You don’t reuse a contaminated needle because it’s more convenient. These are instinctive, non-negotiable practices.

Digital security needs to reach the same level. Three principles:

1. Verify every access. Every login, every device, every access request gets checked - regardless of who is asking or where they are. In security terms this is called “Zero Trust.” In practical terms: check everyone’s ID, every time, even if they work here.

2. Suspect every message. If an email or SMS creates urgency or asks for your credentials, stop. Verify through a separate channel. Call the person who supposedly sent it. This takes 30 seconds and can prevent a breach that costs crores.

3. Never share credentials. No legitimate authority - not your bank, not your IT team, not the police - will ever ask you to share your password or OTP. If someone does, the conversation is over.

India’s Legal Framework

India does not have a single cybersecurity law. Instead, there is a patchwork:

• Information Technology Act, 2000 - Section 43A covers compensation for data breaches. Section 66 criminalises computer offences. Section 72A penalises disclosure of personal information.

• SPDI Rules, 2011 - Mandate “reasonable security practices” for sensitive data including health records.

• Digital Personal Data Protection (DPDP) Act, 2023 - India’s dedicated data protection law. The Data Protection Board became operational in late 2025. Consent-based processing, data minimisation, and real financial penalties for non-compliance.

• CERT-In Directives (2022) - Mandatory 6-hour incident reporting. If you detect a cybersecurity incident, you have 6 hours to report it. Not 6 days, not 6 weeks.

DPDP Healthcare Briefing - Not Legal Advice

244KB ∙ PDF file

Download

Download

The Gap Unlike the US (which has HIPAA) or the EU (which has GDPR with specific health data provisions), India has no dedicated healthcare cybersecurity regulation. Healthcare providers must piece together obligations from multiple laws.

Building Resilience

Zero Trust in practice. Every user verified, every device checked, every network segment isolated. A billing clerk should not have access to clinical records. A radiologist should not have access to financial systems.

Detection and response. You need systems that don’t just block attacks but spot them when they get through. Endpoint Detection and Response (EDR) software watches every device. A Security Information and Event Management (SIEM) system analyses your logs. A Security Operations Centre monitors around the clock - either in-house or outsourced.

People and process. Send your own staff fake phishing emails. Those who click get additional coaching, not punishment. Run incident response tabletop exercises at least once a year. Document who to call and in what order when something goes wrong.

The 3-2-1 backup rule. Three copies of your critical data. Two different types of storage. One copy offsite or physically disconnected from the network. Test restoration quarterly. An untested backup is no backup at all.

Personal Cybersecurity

Passwords and authentication

• Use a password manager. Bitwarden is free and works on everything. Google Password Manager is built into Chrome and Android. You only need to remember one master password.

• Check if your accounts have been breached. Visit haveibeenpwned.com - a free tool that checks whether your email has appeared in any known data breach. If it has, change those passwords immediately. Subscribe for alerts on future breaches.

• Turn on Multi-Factor Authentication (MFA) on every account. Use Google Authenticator or Microsoft Authenticator. This takes two minutes and is one of the best things you can do for your security.

• Never share OTPs. No bank, no government agency, no legitimate service will ever call you and ask for your OTP. If someone does, hang up.

India-specific scams to watch for

• “Digital Arrest” scams - criminals use deepfake video calls to impersonate CBI or police officials, pressuring you into transfers by threatening arrest.

• UPI fraud - fake payment request links or QR codes on WhatsApp or SMS.

• KYC update phishing - SMS messages claiming your bank account will be blocked unless you update KYC details immediately.

Securing your devices

Mobile: Enable biometric lock and a strong PIN. Turn on Find My Device (Android / iPhone). Use encrypted backups. Keep Bluetooth and NFC off when not in use. Download apps only from official stores.

Desktop: Turn on full-disk encryption (BitLocker on Windows, FileVault on Mac - one checkbox in your settings). Keep everything updated. Use a standard (non-admin) account for daily work. Back up regularly.

Network: Change your home Wi-Fi router’s default password. Use WPA3 encryption. Use a VPN on public Wi-Fi - ProtonVPN has a free tier with no data cap.

Securing WhatsApp and Social Media

Let’s be honest: most Indian healthcare professionals use WhatsApp for patient communication daily. It’s fast, it’s convenient, and it’s end-to-end encrypted. The question is not whether you use it, but whether you use it safely.

WhatsApp settings to change now

• Two-Step Verification: Settings → Account → Two-step verification. Set a six-digit PIN. This is the single most important WhatsApp security setting.

• Biometric app lock: Settings → Privacy → App Lock.

• View Once for patient data: When sending X-rays, lab reports, or prescriptions, use View Once. The recipient sees it once, then it’s gone.

• Turn off auto-download: Settings → Storage and Data → switch off auto-download for all media. Otherwise patient files end up in your camera roll, backed up to Google Photos, and accessible to other apps.

• Check linked devices weekly: Settings → Linked Devices. Remove anything you don’t recognise. It takes 10 seconds of physical access to your phone for someone to link your WhatsApp to their laptop.

• No patient data in group chats. You cannot control who screenshots, forwards, or is added to a group. Use one-to-one conversations only.

Patient data red lines

• Never share identifiable patient photos on social media or public groups.

• Don’t store patient data on personal devices - use encrypted, organisationally approved platforms.

• Under the DPDP Act, processing personal health data requires explicit consent.

• Use fake names and altered details when discussing cases in professional forums.

The Long-Term Solution Most Indian hospitals don’t provide a secure, approved alternative to WhatsApp for clinical coordination. Until they do, the precautions above are essential. But the real fix requires organisational investment in compliant communication platforms, not just individual discipline.

Using AI Tools Safely

ChatGPT, Gemini, Copilot and similar tools are finding their way into clinical workflows. Five rules to follow:

1. No patient data goes into AI tools. Strip out names, Aadhaar numbers, hospital IDs, and dates of birth before typing anything. Don’t upload discharge summaries, scans, or reports. Treat every AI chatbox like a postcard, not a sealed letter.

2. Only use tools your hospital has approved. If your hospital hasn’t vetted it, don’t use it for work. Keep a log of which tools are in use across departments.

3. Never act on AI medical output without checking it. AI produces confident, well-written answers that can be completely wrong. Every AI-generated summary, diagnosis, or drug check must be reviewed by a qualified clinician.

4. AI-powered phishing is now very convincing. Criminals use AI to write flawless, personalised phishing emails. “Look for bad grammar” no longer works. If a message feels off, verify the sender by phone.

5. Put a one-page AI policy in place today. Which tools are allowed? What data can go in? Who approves new tools? Write it down and circulate it.

Five Takeaways

1. Cybersecurity is patient safety. When systems fail, care stops. Treat digital security with the same seriousness as infection control.

2. Prepare for when, not if. Paper fallbacks. Crisis WhatsApp groups. Tested backups. Before the attack, not during it.

3. Practise the Digital Sterile Technique. Verify every access. Suspect every message. Never share credentials. Make it instinctive.

4. Your backup is your insurance. Three copies, two media types, one offsite. Test it quarterly.

5. It starts with you, today. Enable MFA. Use a password manager. Turn on WhatsApp Two-Step Verification. Check haveibeenpwned.com. Do it before you close this page.

Quick Reference: Tools You Can Use Right Now

• Password Manager: Bitwarden (free) - generates and stores unique passwords for every account.

• MFA App: Google Authenticator (free) - adds a second verification step beyond your password.

• Breach Check: Have I Been Pwned (free) - checks if your email has appeared in any known data breach.

• VPN: ProtonVPN (free tier, no data cap) - encrypts your traffic on public Wi-Fi.

• Antivirus (Windows): Microsoft Defender (built-in) - already on your machine, good enough for most users.

• Encryption (Windows): BitLocker (built-in on Pro) - full-disk encryption, one checkbox in Settings.

• Encryption (Mac): FileVault (built-in) - System Settings → Privacy & Security → FileVault.

• DNS Protection: Cloudflare 1.1.1.3 (free) - set on your router to block malware domains across all devices.

• Secure Messaging: Signal (free) - end-to-end encrypted, open-source, minimal data collection.

• Ad/Tracker Blocker: uBlock Origin (free) - browser extension that blocks ads, trackers, and malicious domains.

Emergency Contacts

• National Cyber Crime Helpline: 1930

• CERT-In Incident Reporting: incident@cert-in.org.in

• Cyber Crime Reporting Portal: cybercrime.gov.in

Further Reading

• CERT-In - Indian Computer Emergency Response Team

• Data Security Council of India (DSCI)

• Ministry of Electronics and Information Technology (MeitY)

• Chambers and Partners: Cybersecurity 2026 - India Practice Guide

• India Cyber Threat Report 2025 - Seqrite / DSCI

“The best security tool is the one you actually use.”