diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md
new file mode 100644
index 0000000..b69bfb1
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md
@@ -0,0 +1,31 @@
+# Compliance
+
+## Description
+
+This policy enforces that enterprise-class users must authenticate using a device that meets compliance standards defined in Intune.
+
+## Why It's Important
+
+Requiring compliant devices ensures that only endpoints with approved configurations, security controls, and health status can access corporate resources. This policy helps prevent access from unmanaged or misconfigured devices, reducing the risk of data leakage, malware propagation, and unauthorized access. It supports a zero-trust model by validating device posture before granting access.
+
+## Recommendations
+
+- **Communicate** the requirement for compliant devices and provide remediation guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** device compliance enforcement and validate Intune reporting. 
+- **Maintain** a rollback plan for operational resilience. 
+- **Enforce** the policy broadly after successful validation.
+
+
+## License Requirements
+
+- Microsoft Entra ID P1
+- Microsoft Intune
+
+## Learn More
+
+- [Require device compliance with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance){:target="_blank"}
+
+<br>
+
+---
\ No newline at end of file
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md
new file mode 100644
index 0000000..a4170d1
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md
@@ -0,0 +1,30 @@
+# Location
+
+## Description
+
+This policy blocks enterprise identity authentication attempts from specific geographic regions identified as high-risk, based on IP geolocation.
+
+## Why It's Important
+
+Certain countries pose elevated cybersecurity threats due to geopolitical instability, regulatory concerns, or known malicious activity. This policy uses a named location filter to prevent sign-ins from these regions, helping to enforce geo-fencing and reduce exposure to unauthorized access attempts. It supports a zero-trust strategy by ensuring authentication only occurs from trusted geographic zones.
+
+## Recommendations
+
+- **Communicate** the geo-fencing policy and list of blocked regions. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** location-based access behavior and validate named location filters. 
+- **Maintain** a rollback plan for access continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Block access by location](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-by-location){:target="_blank"}
+
+<br>
+
+---
\ No newline at end of file
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md
new file mode 100644
index 0000000..6a5388d
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md
@@ -0,0 +1,30 @@
+# Microsoft Defender for Cloud Applications (MDCA)
+
+## Description
+
+This policy integrates Microsoft Defender for Cloud Apps (MDCA) with enterprise identity access to enable real-time monitoring and control over user sessions.
+
+## Why It's Important
+
+MDCA provides visibility into user activity and enforces session-level controls across cloud applications. By enabling this integration, the policy allows for conditional access enforcement based on risk signals, user behavior, and compliance status. It helps detect anomalies, prevent data exfiltration, and apply granular access restrictions, strengthening enterprise security posture without disrupting productivity.
+
+## Recommendations
+
+- **Communicate** the integration of MDCA and its impact on session monitoring. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** session control behavior and validate MDCA enforcement. 
+- **Maintain** a rollback plan for operational flexibility. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1 
+- Microsoft Defender for Cloud Apps
+
+## Learn More
+
+- [Conditional Access app control in Microsoft Defender for Cloud Apps](https://learn.microsoft.com/en-us/defender-cloud-apps/proxy-intro-aad){:target="_blank"}
+
+<br>
+
+---
\ No newline at end of file
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md
new file mode 100644
index 0000000..a0c6439
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md
@@ -0,0 +1,29 @@
+# Multi-Factor Authentication (MFA)
+
+## Description
+
+This policy enforces multi-factor authentication (MFA) for enterprise identities during sign-in to reduce the risk of identity compromise.
+
+## Why It's Important
+
+Passwords alone are insufficient to protect privileged access. This policy ensures that users in key enterprise groups must verify their identity using a second factor, such as a mobile app or hardware token, before accessing any cloud application. By excluding break-glass accounts, it maintains emergency access while enforcing strong authentication for all other users, supporting a zero-trust security model
+
+## Recommendations
+
+- **Communicate** the MFA requirement and provide setup guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** MFA enforcement and user experience across platforms. 
+- **Maintain** a rollback plan for access continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Require multifactor authentication for all users](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-mfa-strength){:target="_blank"}
+
+<br>
+
+---
\ No newline at end of file
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md
new file mode 100644
index 0000000..8ada825
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md
@@ -0,0 +1,29 @@
+# Authentication Methods
+
+## Description
+
+This policy enforces a specific set of acceptable authentication methods for Entra ID sign-in, based on authentication strength. Only users in the included groups can authenticate, and only if they use approved authentication methods.
+
+## Why It's Important
+
+This policy enforces strong authentication methods for Entra ID sign-ins, ensuring SHIELD limits privileged access to approved, phishing-resistant factors only.
+
+## Recommendations
+
+- **Communicate** the enforcement of strong authentication methods and provide setup guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** authentication strength enforcement and validate exclusions. 
+- **Maintain** a rollback plan for access continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Conditional Access authentication strengths](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths){:target="_blank"}
+
+<br>
+
+---
\ No newline at end of file
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md
new file mode 100644
index 0000000..3f1e2ed
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md
@@ -0,0 +1,29 @@
+# Block Non-Privileged
+
+## Description
+
+This policy prevents non-privileged users from signing in to privileged devices—specifically those designated for sensitive operations. It ensures that only authorized, privileged identities can access high-trust endpoints, reducing the risk of lateral movement, data exposure, or misuse of privileged infrastructure.
+
+## Why It's Important
+
+This policy restricts privileged devices to privileged identities only, ensuring SHIELD prevents unauthorized users from accessing sensitive endpoints and reducing the risk of lateral movement.
+
+## Recommendations
+
+- **Communicate** the restriction of privileged devices to privileged users only. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** access behavior across user types and validate exclusions. 
+- **Maintain** a rollback plan for operational flexibility. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices){:target="_blank"}
+
+<br>
+
+---
\ No newline at end of file
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md
new file mode 100644
index 0000000..32ce73a
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md
@@ -0,0 +1,30 @@
+# Compliance
+
+## Description
+
+This policy enforces that privileged devices must be compliant with their Intune compliance policies before they can access any cloud applications.
+
+## Why It's Important
+
+This policy ensures privileged devices meet Intune compliance requirements before accessing cloud apps, allowing SHIELD to block noncompliant or insecure endpoints from sensitive resources.
+
+## Recommendations
+
+- **Communicate** the requirement for compliant devices and provide remediation guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** device compliance enforcement and validate Intune reporting. 
+- **Maintain** a rollback plan for operational resilience. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+- Microsoft Intune
+
+## Learn More
+
+- [Require device compliance with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-compliance){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md
new file mode 100644
index 0000000..d05a91c
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md
@@ -0,0 +1,29 @@
+# Disable Conditional Access Resilience Downgrade
+
+## Description
+
+This policy prevents Microsoft Entra Conditional Access resilience features from automatically downgrading security requirements during service outages or disruptions. It ensures that privileged identities remain protected even when Microsoft services experience availability issues. Instead of relaxing controls, organizations are expected to use break-glass accounts for emergency access.
+
+## Why It's Important
+
+This policy ensures Conditional Access requirements are never weakened during outages, allowing SHIELD to maintain strong protection for privileged identities and rely on break-glass accounts for continuity.
+
+## Recommendations
+
+- **Communicate** the removal of resilience fallback and reinforce break-glass access procedures. 
+- **Stage** the rollout with a pilot group and validate emergency access. 
+- **Test** behavior during service disruptions and confirm policy enforcement. 
+- **Maintain** a rollback plan for operational continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Conditional Access: Resilience defaults](https://learn.microsoft.com/en-us/entra/identity/conditional-access/resilience-defaults){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md
new file mode 100644
index 0000000..b6a5447
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md
@@ -0,0 +1,29 @@
+# Hardware Enforcement
+
+## Description
+
+This policy ensures that only approved and commissioned hardware is allowed to authenticate to Entra ID. It blocks access from any device that does not meet specific manufacturer, model, and custom attribute criteria—enforcing strict control over the physical devices used by privileged identities.
+
+## Why It's Important
+
+This policy enforces that only approved hardware can access privileged accounts, allowing SHIELD to block untrusted or rogue devices and maintain strict control over sensitive operations.
+
+## Recommendations
+
+- **Communicate** the restriction to approved hardware and provide verification guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** hardware enforcement and validate device attribute filtering. 
+- **Maintain** a rollback plan for operational flexibility. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md
new file mode 100644
index 0000000..bd900cb
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md
@@ -0,0 +1,29 @@
+# Join Type
+
+## Description
+
+This policy ensures that only devices joined directly to Microsoft Entra ID (formerly Azure AD) are allowed to authenticate privileged identities. It blocks access from hybrid-joined or Bring Your Own Device (BYOD) endpoints, helping prevent unauthorized or unmanaged devices from injecting into privileged workflows.
+
+## Why It's Important
+
+This policy restricts privileged access to Entra ID-joined devices only, ensuring SHIELD blocks unmanaged or hybrid endpoints from being used to compromise sensitive workflows.
+
+## Recommendations
+
+- **Communicate** the restriction to Entra ID-joined devices and provide transition guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** device join type enforcement and validate exclusions. 
+- **Maintain** a rollback plan for operational flexibility. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md
new file mode 100644
index 0000000..f0ee218
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md
@@ -0,0 +1,29 @@
+# Legacy Authentication
+
+## Description
+
+This policy blocks the use of legacy authentication protocols—such as Exchange ActiveSync and other non-modern clients—for privileged identities. 
+
+## Why It's Important
+
+This policy blocks legacy authentication for privileged identities, helping SHIELD prevent attackers from exploiting outdated protocols that bypass modern security controls like MFA.
+
+## Recommendations
+
+- **Communicate** the deprecation of legacy authentication and provide transition guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** for legacy protocol usage and validate enforcement. 
+- **Maintain** a rollback plan for operational continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Block legacy authentication with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md
new file mode 100644
index 0000000..f907897
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md
@@ -0,0 +1,29 @@
+# Location
+
+## Description
+
+This policy blocks privileged identity authentication attempts from a set of problematic world regions, as defined by a named location based on IP geolocation. It helps prevent access from countries associated with elevated cybersecurity risks, geopolitical concerns, or regulatory restrictions.
+
+## Why It's Important
+
+This policy blocks privileged access attempts from high-risk or restricted regions, helping SHIELD reduce exposure to malicious activity and comply with geographic access requirements.
+
+## Recommendations
+
+- **Communicate** the geo-fencing policy and list of blocked regions. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** location-based access behavior and validate named location filters. 
+- **Maintain** a rollback plan for access continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Block access by location](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-by-location){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md
new file mode 100644
index 0000000..dd2b2fb
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md
@@ -0,0 +1,29 @@
+# Multi-Factor Authentication (MFA)
+
+## Description
+
+This policy enforces Multi-Factor Authentication (MFA) for privileged users during sign-in to Entra ID. It significantly reduces the risk of identity compromise by requiring a second factor of authentication beyond just a password.
+
+## Why It's Important
+
+This policy enforces MFA for privileged users, helping SHIELD prevent account compromise by requiring an additional factor beyond passwords.
+
+## Recommendations
+
+- **Communicate** the MFA requirement and provide setup guidance. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** MFA enforcement and user experience across platforms. 
+- **Maintain** a rollback plan for access continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Require multifactor authentication for all users](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-mfa-strength){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md
new file mode 100644
index 0000000..29dc392
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md
@@ -0,0 +1,29 @@
+# Operating System Enforcement
+
+## Description
+
+This policy ensures that only devices running Windows are allowed to authenticate to Entra ID. It blocks access from all other operating systems, helping enforce a standardized and secure platform for privileged access.
+
+## Why It's Important
+
+This policy restricts privileged access to Windows devices only, enabling SHIELD to enforce a standardized platform and reduce risks from unmanaged or unsupported operating systems.
+
+## Recommendations
+
+- **Communicate** the change and explain the Windows-only access requirement. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** platform access behavior and validate exclusions. 
+- **Maintain** a rollback plan for operational continuity. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P1
+
+## Learn More
+
+- [Conditional Access: Filter for devices](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices#common-scenarios){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md
new file mode 100644
index 0000000..231ffee
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md
@@ -0,0 +1,29 @@
+# Session Persistence
+
+## Description
+
+This policy disables persistent browser sessions for privileged users, ensuring that identity revalidation occurs as frequently as possible. It helps reduce the risk of unauthorized access due to session hijacking or stale authentication tokens.
+
+## Why It's Important
+
+This policy requires privileged users to reauthenticate frequently, helping SHIELD reduce the risk of session hijacking and misuse of stale tokens.
+
+## Recommendations
+
+- **Communicate** the change to users, highlighting the impact on session behavior. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** authentication frequency and user experience. 
+- **Maintain** a rollback plan to address potential disruptions. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P2
+
+## Learn More
+
+- [Configure adaptive session lifetime policies](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md
new file mode 100644
index 0000000..d1f0f84
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md
@@ -0,0 +1,29 @@
+# Sign-in Risk
+
+## Description
+
+This policy blocks access to Entra ID for users whose sign-in attempts are flagged with any level of risk—low, medium, or high. It’s designed to prevent access from potentially compromised or suspicious sign-in sessions, especially for privileged users.
+
+## Why It's Important
+
+This policy blocks risky sign-ins for privileged users, allowing SHIELD to prevent access from potentially compromised sessions and reduce the chance of account takeover.
+
+## Recommendations
+
+- **Communicate** the policy change and its impact on risky sign-ins. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** sign-in behavior and risk detection accuracy. 
+- **Maintain** a rollback plan for quick recovery if needed. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P2 and a standalone license for Microsoft Defender for Cloud Apps
+
+## Learn More
+
+- [Require multifactor authentication for elevated sign-in risk](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-risk-based-sign-in){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md
new file mode 100644
index 0000000..25b2039
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md
@@ -0,0 +1,29 @@
+# Token Binding
+
+## Description
+
+This policy is designed to prevent token theft from Microsoft Exchange Online (EXO) and SharePoint Online (SPO) clients by enforcing secure session controls for privileged users.
+
+## Why It's Important
+
+This policy protects against token theft by binding access tokens to secure sessions, ensuring attackers cannot reuse stolen tokens to bypass SHIELD identity and access controls.
+
+## Recommendations
+
+- **Communicate** the policy change and its impact to affected users. 
+- **Stage** the rollout by piloting with a small, controlled group. 
+- **Test** functionality and user experience across supported platforms. 
+- **Maintain** a rollback plan to quickly respond to any issues. 
+- **Enforce** the policy broadly once validated and stable.
+
+## License Requirements
+
+- P2 License
+
+## Learn More
+
+- [Token Protection in Microsoft Entra Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md
new file mode 100644
index 0000000..e4bf22d
--- /dev/null
+++ b/docs/SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md
@@ -0,0 +1,29 @@
+# User Risk
+
+## Description
+
+This policy blocks access to Entra ID for users who are flagged with any level of user risk—low, medium, or high—as determined by Microsoft Entra ID’s risk detection engine. It’s designed to protect privileged access by preventing authentication from accounts that may be compromised.
+
+## Why It's Important
+
+This policy blocks privileged access for accounts flagged with user risk, helping SHIELD prevent compromised identities from authenticating and protecting sensitive operations.
+
+## Recommendations
+
+- **Communicate** the policy change and how user risk affects access. 
+- **Stage** the rollout with a pilot group and exclude critical accounts. 
+- **Test** risk detection accuracy and user impact. 
+- **Maintain** a rollback plan for rapid response to issues. 
+- **Enforce** the policy broadly after successful validation.
+
+## License Requirements
+
+- Microsoft Entra ID P2 and a standalone license for Microsoft Defender for Cloud Apps
+
+## Learn More
+
+- [User risk detections](https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#user-risk-detections){:target="_blank"}
+
+<br>
+
+---
diff --git a/docs/SHIELD/Deploy/Usage-Guide.md b/docs/SHIELD/Deploy/Usage-Guide.md
index 44cc914..4e5edce 100644
--- a/docs/SHIELD/Deploy/Usage-Guide.md
+++ b/docs/SHIELD/Deploy/Usage-Guide.md
@@ -16,6 +16,9 @@ After core deployment is complete, the Deploy module allows you to:
 
 These actions are performed through the **Lifecycle Infrastructure** interface on the SHIELD home screen.
 
+!!! info "Additional Information"
+    For more information on how SHIELD evaluates tenant configuration against baselines and produces the architectural report, see [Architectural Analysis Overview](../../SHIELD/Reference/Architecture/Architectural-Analysis-Overview.md).
+
 ---
 
 ## Defender for Endpoint Workspace Creation
@@ -76,6 +79,7 @@ Once core deployment is complete, your SHIELD UI will provide management cards f
 
 ## Related Pages
 
+- [Architectural Analysis Overview](../../SHIELD/Reference/Architecture/Architectural-Analysis-Overview.md)
 - [Deploy Overview](index.md)
 - [Deployment Guide](../Getting-Started.md)
 - [Reference Docs](Reference/index.md)
diff --git a/docs/SHIELD/Discover/assets/images/screenshots/Pricing_Table.png b/docs/SHIELD/Discover/assets/images/screenshots/Pricing_Table.png
new file mode 100644
index 0000000..60e3331
Binary files /dev/null and b/docs/SHIELD/Discover/assets/images/screenshots/Pricing_Table.png differ
diff --git a/docs/SHIELD/Discover/assets/images/screenshots/shield_discover_module_data_flow.jpg b/docs/SHIELD/Discover/assets/images/screenshots/shield_discover_module_data_flow.jpg
new file mode 100644
index 0000000..d2eaab8
Binary files /dev/null and b/docs/SHIELD/Discover/assets/images/screenshots/shield_discover_module_data_flow.jpg differ
diff --git a/docs/SHIELD/Prerequisites/Installation.md b/docs/SHIELD/Prerequisites/Installation.md
new file mode 100644
index 0000000..b0def31
--- /dev/null
+++ b/docs/SHIELD/Prerequisites/Installation.md
@@ -0,0 +1,144 @@
+# Overview and Installation Requirements
+
+!!! info "Security Considerations"
+    While this application requires sensitive permissions to conduct the automated scan, by self-hosting the application, SHI does not represent a supply chain risk or path to compromise a customer environment via the SHIELD platform, as there is no control maintained beyond the initial point of installation. All code being run to conduct the automated discovery is available for code & security reviews prior to engagement upon request. Permissions exist for both the user initiating the report & the application itself. Code review is available upon request.
+
+## Overview
+
+This application is a self-hosted application that exists in the customer tenant on an Azure App Service, collecting and processing the requisite data only within the customer tenant before provided abstracted & fully anonymized data results back to SHI for reporting. All requirements can be set up by the delivery team or customer prior to engagement.
+
+---
+
+## Setup Steps/Requirements
+
+### Using SHIELD - Desktop's Installer module
+
+1. Create new Dedicated Azure Subscription.
+2. Run the installer to set up SHIELD automatically.
+
+---
+
+### Deploying by hand
+
+1. Create new Dedicated Azure Subscription.
+2. Install PowerShell Dependencies
+    - Latest [v7](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell){:target="_blank"} release installed (ideally from the [Microsoft Store](https://www.microsoft.com/store/productId/9MZ1SNWT0N5D){:target="_blank"})
+    - Modules: [Az](https://www.powershellgallery.com/packages/Az){:target="_blank"}, [Microsoft.Graph.Beta](https://www.powershellgallery.com/packages/Microsoft.Graph.Beta){:target="_blank"}
+    - Scripts: [Grant-MIGraphPermission](https://www.powershellgallery.com/packages/Grant-MIGraphPermission){:target="_blank"}
+3. Create a new resource group named: `SHIELD`
+4. Create a new Azure App Service (Web App)
+    - OS: Linux
+    - Minimum SKU: P0v4
+    - Runtime Stack: Node 24 LTS
+    - Azure Cost Estimate associated (as of 1/8/2025):
+
+| Premium v4 Service Plan | vCPU(s) | RAM | Storage | Pay as you go | 1 year savings plan | 3 year savings plan | 1 year reserved | 3 year reserved |
+|-----------------|-------------------|---------------------|-----------------|-------------------|---------------------|-----------------|-------------------|---------------------|
+| P0v4 | 1 | 4 GB | 250 GB | **$86.870**/month | **$70.365**/month ~ 19% savings | **$58.203**/month ~ 33% savings | **$65.000**/month ~ 25% savings | **$53.831**/month ~ 38% savings |
+| P1v4 | 2 | 8 GB | 250 GB | **$173.740**/month | **$140.730**/month ~ 19% savings | **$116.406**/month ~ 33% savings | **$130.086**/month ~ 25% savings | **$107.668**/month ~ 38% savings |
+
+## Permissions
+
+- The User logging in to SHIELD: Discover requires either Global Admin or the following:
+    - Global Reader
+    - Security Administrator
+    - User Administrator
+- **The service principal (System Assigned Managed identity is recommended) must be granted**:
+    - `Owner` for the Azure Subscription assigned to app
+    - `AppRoleAssignment.ReadWrite.All`
+    - `Application.ReadWrite.All`
+    - [Additional permissions](../Prerequisites/Required-Graph-API-Permissions.md) will be self-assigned by the app to save time and begin data collection.
+
+### Networking
+
+- Network Endpoints:
+    - <https://api.shilab.com>
+    - <https://url.shilab.com>
+    - https://*.azurewebsites.net
+- Disable network traffic inspection/unwrapping/decryption
+    - According to [Microsoft Documentation](http://aka.ms/pnc){:target="_blank"}, Traffic Inspection of any kind via a tool like Palo, Zscaler, or nginx (caching) violates Microsoft's Terms & Conditions (as well as each major cloud provider) as traffic that was decrypted and is heading to Microsoft is indistinguishable from man in the middle attacks.
+    - As a result, all traffic inspected is promptly dropped by Microsoft. As we rely on Azure Networking for SHIELD to run, this prevents SHIELD from functioning.
+    - Please validate that **ALL** Microsoft traffic is excluded from any form of Network Inspection: this is a requirement for SHIELD to function, as it is against Microsoft's terms and conditions.
+
+---
+
+## Data Security
+
+### SHI Lab Azure Architecture
+
+- Regulatory compliance standards: [https://servicetrust.microsoft.com/](https://servicetrust.microsoft.com/){:target="_blank"}
+- Encryption at rest (mandatory)
+- Encryption in transit (mandatory)
+    - Quantum resistant algorithms only
+    - Latest TLS version for resource only
+- CRUD Audit
+    - SQL Audit is enabled too
+- Access Audit (Mandatory)
+- Full micro-segmentation (address/port enforcement for all resources)
+- Data-store behind API, no internet access
+- SSO Access Only (no cred vaulting workarounds, pure modern SSO, credential-less only)
+- MFA for all authentication is mandatory
+- Human-free production-only design
+    - Access to the Production environment is limited to only highly critical incidents.
+- Debug access is severely limited
+- No Operating Systems
+    - Pure Serverless
+    - Always up to date
+    - No custom execution except for designed workload (no viruses possible)
+    - No update downtime
+    - Vulnerability patching done before public announcement of vulnerability
+    - Self-healing
+
+### Miscellaneous Considerations
+
+- No customer data is used in any environment except for production
+- Environment is only production only, reducing surface area of attack
+    - No dev or test environments
+    - Prod only via ring deployment and feature flags
+- All tooling can run locally so that no production access is required for testing, development and debugging
+- No on-premise systems, all resources are cloud only including end user compute/systems
+- Hardware supply chain is strictly enforced
+- Surface devices are only allowed at all levels of end user compute
+- Firmware credentials are set to cert auth on all endpoints
+- Device source code available for review: [https://microsoft.github.io/mu/](https://microsoft.github.io/mu/){:target="_blank"}
+
+---
+
+## Data Structure
+
+### High-level Data Flow Diagram
+
+SHIELD: Discover does not collect PII or similar data – it is only focused on the scope of configurations within the Microsoft security stack, and not on any private employee or customer data. Specifics on what data collected is listed in the next section.
+As a self-hosted application, data collected lives in the customer environment until it is anonymized and sent to SHIELD's database via the Data Gateway. The Data Gateway structure is available to review upon request.
+
+```mermaid
+flowchart LR
+SHI[SHI]
+
+subgraph tenant["Customer Tenant"]
+    serviceConfiguration[Service Configuration Scope Noted to Object ID. Configuration **not** recorded]
+    tenantConfiguration[Tenant Configuration Observed, such as a Conditional Access policy]
+    objectIDs[Object IDs in Scope Determined]
+end
+
+serviceConfiguration --> tenantConfiguration
+tenantConfiguration --> objectIDs
+objectIDs --> serviceConfiguration
+
+SHI -.Initial Installation.-> tenant
+serviceConfiguration-->|Object IDs with associated Scopes reported to Data Gatway, no PII Associated| SHI
+```
+
+### Example Data Structure & Output
+
+SHIELD Discover collects the following data:
+
+- Tenant ID
+- Principal ID that saved the report
+- Principal ID that ran the report
+- Principle Object ID
+    - Assigned License – The Service Plan IDs of the license(s) that are assigned (direct or indirect) to the specific principal
+    - Assigned Services – The service configuration assignment determining 'benefitting' from a service. This includes the service configuration type if possible (feature, such as 'Conditional Access,' a service within the Entra ID license)
+    - Consumed Services – Usage telemetry retrieved to indicate if the specific principal is consuming/using the service, regardless of license status
+
+For a complete look at the Data Structure, please refer to the [Data Gateway API Spec](https://specs.shilab.com/){:target="_blank"}.
\ No newline at end of file
diff --git a/docs/SHIELD/Reference/Architecture/Architectural-Analysis-Overview.md b/docs/SHIELD/Reference/Architecture/Architectural-Analysis-Overview.md
new file mode 100644
index 0000000..53d72f4
--- /dev/null
+++ b/docs/SHIELD/Reference/Architecture/Architectural-Analysis-Overview.md
@@ -0,0 +1,127 @@
+
+The SHIELD system runs a full architectural analysis by gathering tenant data, runs a parallel analysis on all configuration items, and saves the results. Afterward, tenant data is compared to the baseline configuration, and a report is generated. This overview provides a more detailed outline of this process.
+
+## Input Validation & Locking
+When the scan is deployed, the system checks if there is already an analysis in progress. 
+
+- If there is no scan occurring, the system locks the engine to begin the analysis and moves on the next step.
+- If there is a scan is in progress, the button is disabled to prevent concurrent operations. 
+
+## Progress Bar
+Once the analysis begins, a progress bar displays the status of three different steps:
+
+1. **Retrieving Tenant Metadata**
+2. **Analyze Architecture** (During which a sub-progress bar is displayed for each baseline configuration, along with the status of the analysis)
+    1. Gathering data from tenant
+    2. Comparing tenant data to the baseline configuration
+    3. Building report
+    4. Status
+        - **Done** - Displayed once the analysis is finalized and there are no errors reported.
+        - **Error** - Displayed if a critical error is hit during any of the three previous checkpoints.
+3. **Saving Architecture Report**
+
+### 1. Retrieving Tenant Metadata
+The system gathers metadata, such as users and devices, associated with the current tenant and architecture, via the `initializeArchitectureReport()` function. The data is then stored in the system, so it can be analyzed in the next step. 
+
+#### Information Stored
+Data is stored in one of two ways:
+
+1. **Raw data** for all Conditional Access policy configurations is retrieved from the Azure tenant. This information is cached in application memory for the duration of the analysis. This is automatically cleared in the step immediately before the engine lock is released.
+2. **Summary data** of the architectural analysis report is retained in a digital repository according to our data retention policy. The data is mostly Universally Unique Identifiers (UUIDs), numbers, and dates. This includes:
+    - A unique identifier that represents each run of the architectural analysis
+    - Tenant ID under analysis
+    - Total users in the tenant
+    - Total guest users in the tenant
+    - Total member users in the tenant
+    - Total devices associated with the tenant
+    - The principal name associated with the user used to authenticate into the tenant being audited
+    - User account used to store and report the architecture report to SHI
+    - Timestamp when the record was created
+    - Timestamp when the record was last updated
+    - A list of UUIDs corresponding to users and their associated SHIELD baseline configuration items
+        - The list also includes a string, specifying if a tenant policy was found that matches the baseline policy, classified as either 'full' or 'partial'. User identifiers with no 'full' or 'partial' matches are excluded.
+
+### 2. Analyze Architecture
+All the SHIELD baseline configurations are added to a list, and each configuration is analyzed independently via the `analyzeArchitecture()` function. During this step the system will:
+
+- Retrieve live data from the tenant (e.g., Microsoft Graph)
+- Compare tenant data to baseline configuration
+- Record discrepancies, matches, and assignments
+- Report findings back to the deploy engine
+
+### 3. Saving the Architecture Report
+Once all the configuration items have been analyzed, a report is created via the `saveArchitectureReport()` function. This serializes and saves the results of the analysis, including findings, discrepancies, and additional metadata for later review and reporting.
+
+## Finalization
+Once the system is finished with the analysis and the report has been saved, the timestamp of the last analysis is updated. Next, the graph data cache is cleared, and the engine is unlocked. If the system ran into any errors during the process, those are also logged. 
+
+## Summary Table
+
+|            | Responsibility |
+|------------|----|
+|`analyze`|	Begins the entire Architectural Analysis process, analyzing all configuration items in the architecture |
+|`analyzeArchitecture()`|	An asynchronous analyzation method called on each item in the configuration list |
+|`configurationItemList`|	A list of all the configuration items that were gathered during the retrieval phase |
+|`DeployEngine`|	The engine that powers the system running the Architectural Analysis |
+|`initializeArchitectureReport()`|	Gathers and stores metadata about the current tenant and architecture |
+|`isDeploying`|	Checks if the system is running a scan or deploying a policy |
+|`Promise.all`|	Analysis operations are collected into a list and executed in parallel |
+|`saveArchitectureReport()`|	Saves the results of the analysis and stores the results |
+|`writeDebugInfo`|	Logs errors that occur during analysis |
+
+---
+
+## Conditional Access Policies
+
+To get a better understanding of the analysis process and how the system compares customer policies to baseline policies, let's look at a specific policy. For Conditional Access Policies, the system analyzes a single Conditional Access Policy configuration item via the `analyzeConditionalAccessPolicy` function, a specialized analysis function. There are three steps to analyzing a Conditional Access Policy:
+
+1. **Type Validation** - The system checks if the configuration item is a valid instance or not. 
+2. **Create New Instance** - A new instance of `CspmConditionalAccess` is created, passing the configuration item and `graphBeta` flag. 
+3. **Delegation to Internal Analysis** - Data is gathered and analyzed via the `analyzeConditionalAccessPolicyInternal()` function.
+
+### Delegation to Internal Analysis
+
+#### Locking
+During this step, the system will check if there is already an analysis in progress. If not, the system locks the engine to begin the analysis.
+
+#### Progress Bar
+Once the analysis begins, a progress bar displays the status of each step.
+
+#### Data Fetch
+
+The system calls the `getCustomerTenantGraphData()` function to analyze the current Conditional Access Policies from Microsoft Graph.
+
+#### Comparison
+
+The `compareConditionalAccessPolicy()` function validates the URL path and calls the `compareConditionalAccessPolicies()` function, which does the following:
+
+- Scans the baseline configuration
+- Compares each policy to the baseline
+- Assess the degree of match, either 'full', 'partial', or 'none'
+    - **Full Coverage**: All of in scope are fully covered by the policy. The policy matches the baseline for every user.
+    - **Partial Coverage**: A percentage of users in scope are covered by the policy, but the policy only partially matches the baseline for those users. 
+    - **No Coverage**: No users are covered by the policy. The policy does not provide any baseline coverage. 
+    - **Unassigned**: Users are not assigned to the deployed policy. 
+- Builds an assignment and exclusion list for reporting
+
+#### Reporting
+
+A report is created via the `sendConfigurationMatchAssessmentToDeployEngine()` function to record the results found in the previous steps.
+
+#### Error Handling & Unlocking
+
+Errors are logged and updated in the progress bar, and the lock is then released.
+
+## Summary Table
+
+|	| Responsibility |
+|---|----------------|
+|`analyzeConditionalAccessPolicy`|	Analyzes a single Conditional Access policy configuration item
+|`analyzeConditionalAccessPolicyInternal()`|	Analyzes the Conditional Access Policies internally
+|`compareConditionalAccessPolicies()`|	Scans the baseline configuration, compares each policy to the baseline, assesses the degree of match, and builds a list for reporting
+|`compareConditionalAccessPolicy()`|	Validates the URL path and prepares the system to compare Conditional Access Policies
+|`ConfigurationItem.analyzeArchitecture()`|	Delegates each configuration item to the correct analyzer
+|`CspmConditionalAccess`|	Implements the logic for fetching, comparing, and reporting Conditional Access policies
+|`DeployEngine.analyze()`|	Orchestrates analysis for all configuration items in the architecture
+|`getCustomerTenantGraphData()`|	Pulls in the current Conditional Access Policies from Microsoft Graph
+|`sendConfigurationMatchAssessmentToDeployEngine()`|	Records the results of the analysis and creates an architecture report
\ No newline at end of file
diff --git a/docs/SHIELD/Reference/Break-Glass-Overview.md b/docs/SHIELD/Reference/Break-Glass-Overview.md
new file mode 100644
index 0000000..30e8127
--- /dev/null
+++ b/docs/SHIELD/Reference/Break-Glass-Overview.md
@@ -0,0 +1,80 @@
+# Break Glass Accounts
+
+## Overview
+
+A break glass account, or [emergency access account](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access){:target="_blank"}, is a highly privileged, unlicensed, emergency access mechanism used to regain access to critical resources that can be used to recover systems. Typically, when standard administrative accounts are unavailable, due to outages, conditional access misconfiguration, Multi-Factor Authentication (MFA) failures, or account lockouts.
+
+---
+
+## Getting Started
+
+It is strongly recommended to maintain two break glass accounts. One account is designated as the primary and the other as a backup. This provides a fail-safe mechanism should the primary account be inaccessible for any reason.
+
+- Break glass accounts need to be excluded from all security controls.
+- These accounts must retain full functionality at all times. Any restrictions could lead to critical outages and operational disruptions.
+- Be sure to test the account login immediately after creation to ensure validity.
+
+---
+
+## Storage Methods
+
+### Offline Physical Storage
+
+A break glass packet should be enclosed in a sealed, tamper-evident, waterproof container stored in a physically secured location such as a company safe, safe deposit box, or vault.
+
+#### Break Glass Packet
+
+Each break glass packet should include two of the following printed out:
+
+- Account username and password
+- Detailed login instructions including the specific account to access such as "entra.microsoft.com", "portal.azure.com", "admin.microsoft.com".
+- Two FIDO2 keys (YubiKeys are recommended); one primary and one backup in case the primary key breaks. Both break glass accounts should be stored on each security key.
+    - **Note**: Multi-Factor Authentication (MFA) is mandatory, even for emergency access accounts.
+    - PINs for FIDO2 (Fast IDentity Online 2) pins need to be randomly generated and included on the papers. For more information about FIDO2, see [What is FIDO2?](https://www.microsoft.com/en-us/security/business/security-101/what-is-fido2){:target="_blank"}
+        - **Note**: You can have multiple FIDO2 credentials stored on a single security key.
+
+#### Passwords
+
+- Passwords must be a minimum of 32 characters; 64 characters are recommended, although the longer the password the better.
+- The password should not be human generated. It must be completely randomly generated by a credential vaulting solution and set on the account.
+- Passwords should be printed using a monospaced typeface, such as Consolas.
+    - This prevents confusing similar-looking characters such as the numeral zero (0) and the uppercase letter 'O', as well as the numeral one (1), lowercase 'L' (l) and uppercase 'i' (I). Since the passwords are long, it is easy to input the wrong character and not know where you made the mistake.
+- Passwords must be changed immediately after every usage session (after emergency is resolved).
+
+#### Printing
+
+- Use a Secure Printer
+    - Print passwords only on a printer that does not store printed materials.
+    - Most multi-function printers (MFPs) have internal storage that retains print jobs in plain text.
+    - If using an MFP, remove and securely erase the hard drive after printing.
+- Ensure Privacy During Printing
+    - Confirm that no security cameras are directed toward the printer.
+        - Cameras can capture printed content, and anyone with access to footage could obtain privileged credentials.
+    - Ensure that unauthorized personnel are not present during printing.
+    - Ensure that people are not present with Eidetic (photographic) memory/total recall or are familiar with fast memorization techniques.
+- Print and Store Copies
+    - Print two copies of the packet for each break glass storage location.
+        - Store the copies inverted relative to each other to minimize the impact of water damage.
+        - If water damage occurs, it typically affects only part of the packet, allowing reconstruction from unaffected sections.
+    - If you do not have a secondary location, consider using a safe deposit box.
+- Maintain Redundancy
+    - Keep two complete sets in each location to ensure availability if one set is damaged.
+
+---
+
+## Additional Considerations
+
+### Auditing
+
+Break glass accounts should be monitored and audited as much as possible. It is essential to track all activities associated with these accounts, as they operate without restrictions.
+
+- Break glass accounts should not be excluded from auditing controls.
+
+### Notifications
+
+Notifications must be set up inside of the security information and event management (SIEM) solution of your choice to ensure timely alerts. Notifications should include phone calls, emails, and text messages sent to everyone in the chain, especially the person in charge of information technology, such as the Chief Information Officer (CIO), Chief Information Security Officer (CISO), Director of Information Technology (IT), or equivalent. All security personnel must be alerted if there is:
+
+- Any successful sign-in from a break glass account
+- Any password reset or modification
+
+**Note**: Notifications may take up to 5 minutes after authentication, due to a limitation in log analytics if using Microsoft Sentinel.
diff --git a/mkdocs.yml b/mkdocs.yml
index a548ae6..f7ddd79 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -145,6 +145,7 @@ nav:
       - Overview: SHIELD/index.md
       - Prerequisites:
           - Overview: SHIELD/Prerequisites/index.md
+          - Installation: SHIELD/Prerequisites/Installation.md
           - Graph API Permissions: SHIELD/Prerequisites/Required-Graph-API-Permissions.md
       - Getting Started: SHIELD/Getting-Started.md
       - Usage Guide: SHIELD/Usage-Guide.md
@@ -153,7 +154,32 @@ nav:
           - Overview: SHIELD/Deploy/index.md
           - Deployment: SHIELD/Deploy/Deployment/index.md
           - Usage Guide: SHIELD/Deploy/Usage-Guide.md
-          - Reference: SHIELD/Deploy/Reference/index.md
+          - Reference:
+            - Reference: SHIELD/Deploy/Reference/index.md
+            - Architecture:
+              - SHIELD:
+                - Enterprise:
+                  - Conditional Access:
+                    - Compliance: SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Compliance.md
+                    - Location: SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/Location.md
+                    - Microsoft Defender for Cloud Applications (MDCA): SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MDCA.md
+                    - Multi-Factor Authentication (MFA): SHIELD/Deploy/Reference/Architecture/SHIELD/Enterprise/Conditional-Access/MFA.md
+                - Privileged:
+                  - Conditional Access:
+                    - Authentication Methods: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Authentication-Methods.md
+                    - Block Non-Privileged: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Block-Non-Priv.md
+                    - Compliance: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Compliance.md
+                    - Disable Conditional Access Resilience Downgrade: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Disable-CA-Resilience-Downgrade.md
+                    - Hardware Enforcement: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Hardware-Enforcement.md
+                    - Join Type: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Join-Type.md
+                    - Legacy Authentication: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Legacy-Auth.md
+                    - Location: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Location.md
+                    - Multi-Factor Authentication (MFA): SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/MFA.md
+                    - Operating System Enforcement: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/OS-Enforcement.md
+                    - Session Persistence: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Session-Persistence.md
+                    - Sign-in Risk: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Sign-In-Risk.md
+                    - Token Binding: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/Token-Binding.md
+                    - User Risk: SHIELD/Deploy/Reference/Architecture/SHIELD/Privileged/Conditional-Access/User-Risk.md
           - Troubleshooting: SHIELD/Deploy/Troubleshooting.md
 
       - Defend:
@@ -215,6 +241,7 @@ nav:
       - Reference:
           - Architecture:
               - Overview: SHIELD/Reference/Architecture/index.md
+              - Architectural Analysis Overview: SHIELD/Reference/Architecture/Architectural-Analysis-Overview.md
               - Threat Model: SHIELD/Reference/Architecture/Threat-Models/ISV-To-Customer.md
               - Review Template: SHIELD/Reference/Architecture/Review-Template.md
           - Development:
@@ -223,6 +250,7 @@ nav:
               - Configure Managed Identity: SHIELD/Reference/Settings/Configure-Managed-Identity.md
               - Debug Mode: SHIELD/Reference/Settings/Debug-Mode.md
               - Environment Variables: SHIELD/Reference/Settings/Environmental-Variables-Reference.md
+          - Break Glass: SHIELD/Reference/Break-Glass-Overview.md
           - Uninstall: SHIELD/Reference/Uninstall.md
 
   - Data Gateway: