Why Layers and Models Matter
Cybersecurity professionals rely on structured models to understand complex systems. In textbooks, frameworks, and certifications, we see layers and planes: the OSI model for networking, NIST’s control families, Zero Trust pillars, and layered defense models. These abstractions don’t exist just for theory — they allow professionals to communicate, reason, and govern systems at scale.

At the same time, modern software is built and understood through the lens of Object-Oriented Programming (OOP). Software engineers don’t try to understand a program by clicking around its interface; they model it in terms of classes, objects, methods, inheritance, encapsulation, and interfaces. The interface is just the surface. The system itself lives in its object structure and logic.

Microsoft Entra ID is inherently an OOP system. Its entities are objects, its rules are methods, and its relationships are defined through inheritance and encapsulation. But Microsoft does not present Entra this way. Instead, it presents Entra as a control panel — a graphical user interface (GUI) with menus and toggles. That GUI is useful for administration, but it is not how you truly understand the system.

Consider these realities:
– A software engineer does not “understand” code by looking at an IDE toolbar — they understand it by mapping the program’s classes and methods.
– A network engineer does not “understand” a protocol by looking at router knobs — they understand it by tracing the OSI model.
– In the same way, an identity professional cannot truly “understand” Entra ID just by navigating the Azure portal. To reason about it, you need to see the object model beneath it and the layered framework it operates in.

⸻

The ClarityStack Methodology

The EntraID Blueprint (CAF-Entra) is the product of Intelligent Architecture’s artificial intelligence systems architecture work. We built it through ClarityStack, a reverse engineering methodology developed to analyze and remap Microsoft Entra ID into a governance-ready model.

ClarityStack consists of five engineering techniques:

– Abstract Layering – Isolating and stratifying logical constructs (e.g., separating identity from access).
– System Architecture Modeling – Mapping components and boundaries as a formal system.
– Control Surface Mapping – Identifying enforcement and configuration vectors.
– Structural Coupling and Interface Design – Understanding how elements relate as loosely or tightly coupled systems.
– Feedback and Observability – Analyzing how Entra surfaces state, logs, alerts, and risk through telemetry.

Using these techniques, we decomposed Entra ID into its true OOP structure and then reassembled it into two complementary layered models:

– The Six Engineering Planes (conceptual framework, vertical).
– The Seven Enforcement Layers of the Entra Control Stack (operational enforcement, horizontal).

⸻

The Six Engineering Planes

These six planes describe Entra’s conceptual behavior — what is happening.

1– Identity Plane
– Governs the creation and definition of digital identities (users, groups, service principals, devices).
– Anchors the directory as the system of record.
– OOP Analogy: Class instantiation.

2– Authentication Plane
– Governs the proof of identity (MFA, passwordless flows, risk-based sign-in).
– Ensures objects validate state before invocation.
– OOP Analogy: Constructor validation.

3– Authorization Plane
– Governs post-authentication rights (RBAC, PIM, delegated scopes).
– Enforces least privilege and privilege boundaries.
– OOP Analogy: Method invocation control.

4– Access Plane
– Governs runtime contextual enforcement (Conditional Access, session controls, location/device conditions).
– Decides whether an object can interact with a resource under defined conditions.
– OOP Analogy: Interface contract.

5– Device Plane
– Governs devices as first-class identity objects with compliance state and trust signals.
– Integrates device health into identity enforcement.
– OOP Analogy: Composite objects.

6– Continuous Verification Plane
– Governs ongoing risk evaluation and adaptive trust (Identity Protection, anomaly detection, token revocation).
– Ensures identity trust is dynamic, not static.
– OOP Analogy: Runtime assertion checks.

⸻

The Entra Control Stack: Seven Enforcement Layers

Where the Six Planes describe conceptual architecture, the Control Stack defines operational enforcement — where and how controls are applied. These layers map the real-world enforcement surfaces of Entra.

– Layer 1: Authority Definition
– Purpose: Establishes who or what holds ultimate control in the tenant.
– Core Entra Elements: Tenant root, Global Admin role, tenant-wide config anchors.
– Compliance Anchors: SOX (role segregation), ISO 27001 A.6 (governance structure).
– Configuration Focus: Limit Global Admins, document authorities, enforce privileged access reviews.

– Layer 2: Scope Boundaries
– Purpose: Segments Entra into bounded domains of control.
– Core Elements: Administrative Units, management groups, subscription boundaries.
– Compliance Anchors: NIST AC-6, CIS v8 §5.
– Configuration Focus: Use AUs to limit scope, align boundaries to org hierarchy.

– Layer 3: Test Identity Validation
– Purpose: Validates policies with test objects before production.
– Core Elements: Test accounts, simulation logs, PIM elevation records.
– Compliance Anchors: ISO 27001 A.12.1, SOC 2 CC5.3.
– Configuration Focus: Maintain test tenants/accounts, run Conditional Access “what-if” tools.

– Layer 4: External Entry Controls
– Purpose: Governs how external identities (B2B, B2C, cross-tenant) enter.
– Core Elements: Guest settings, cross-tenant policies, federation.
– Compliance Anchors: GDPR, NIST IA-8.
– Configuration Focus: Restrict guest defaults, enforce inbound CA, apply least-privileged external sharing.

– Layer 5: Privilege Channels
– Purpose: Controls privilege escalation and delegation.
– Core Elements: Privileged Identity Management (PIM), eligible vs. active role assignments.
– Compliance Anchors: SOX, PCI-DSS 7.2, ISO 27001 A.9.2.
– Configuration Focus: Require approvals, enforce MFA on activation, audit stale assignments.

– Layer 6: Device Trust Enforcement
– Purpose: Applies controls based on device identity and compliance state.
– Core Elements: Intune device policies, join states, CA device filters, Defender signals.
– Compliance Anchors: HIPAA §164.308, CIS §4.
– Configuration Focus: Require compliant devices, enforce CA filters, log device failures.

– Layer 7: Continuous Verification
– Purpose: Provides ongoing trust evaluation during and after sign-in.
– Core Elements: Identity Protection, risk-based CA, anomaly detection, token revocation.
– Compliance Anchors: NIST 800-207, ISO 27001 A.12.4.
– Configuration Focus: Enable risk-based CA, monitor anomalies, enforce real-time token revocation.

⸻

Framework vs. Control Stack

Six Engineering Planes (Framework):
– Provide conceptual architecture (what is happening).
– Six vertical planes (Identity, Authentication, Authorization, Access, Device, Continuous Verification).
– Categorize behaviors and structure them for reasoning.
– Orientation: Abstract → Structural.
– Product use: Anchor modules by conceptual behavior.

Seven Enforcement Layers (Control Stack):
– Provide operational enforcement (where and how it is happening).
– Seven horizontal layers (Authority Definition through Continuous Verification).
– Govern control points and enforcement boundaries.
– Orientation: Practical → Operational.
– Product use: Anchor modules by enforcement surface.

Together:
– Planes = What is happening conceptually.
– Layers = Where and how it is enforced.

⸻

The 21×14 Structure

ClarityStack also gave us the discipline to break Entra into a 21 module × 14 section grid (294 reasoning units). This 21×14 structure is not arbitrary — it ensures that a sprawling, complex identity system can be decomposed into repeatable, auditable components.

Each module isolates a domain (e.g., lifecycle, policies, tokens, external identities). Each section applies a consistent analysis lens (plain explanation, OOP mapping, compliance, risk, framework anchoring, etc.).

The result is a complete, auditable map of Entra ID. Instead of wandering through menus in the GUI, professionals can reason about each piece of the system in its true nature — as OOP constructs anchored in layered planes and enforcement layers.

⸻

The Core Contribution

– We revealed Entra’s inherent OOP system.
– We applied layering discipline through both planes and enforcement layers.
– We structured the knowledge in a 21×14 matrix, ensuring no critical surface was left unmapped.
– We separated analysis from interface, giving professionals a durable way to understand Entra regardless of how the Azure portal evolves.
– We built this through Intelligent Architecture’s artificial intelligence systems architecture, proving that AI can reverse-engineer and re-map a complex identity platform into a governance-ready framework.

This is why the EntraID Blueprint (CAF-Entra) is not just documentation — it is a governance reasoning system. It gives professionals the map of the terrain before they step into the control tower of the GUI.