<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Common RADIUS Reference Architectures on Keytos Docs</title>
    <link>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/</link>
    <description>Recent content in Common RADIUS Reference Architectures on Keytos Docs</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <copyright>ALL RIGHTS RESERVED. © 2026 Keytos</copyright>
    <lastBuildDate>Fri, 24 Apr 2026 12:00:00 -0700</lastBuildDate>
    <atom:link href="https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How-To: Add a Default/Fallback RADIUS Policy That Matches When No Other Policies Match</title>
      <link>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/default-fallback-radius-policy/</link>
      <pubDate>Fri, 24 Apr 2026 12:00:00 -0700</pubDate>
      <guid>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/default-fallback-radius-policy/</guid>
      <description>&lt;h2 data-toc-text=&#34;Overview&#34; id=&#34;overview---how-to-add-a-defaultfallback-radius-policy&#34;&gt;Overview - How to Add a Default/Fallback RADIUS Policy&lt;a class=&#34;td-heading-self-link&#34; href=&#34;#overview---how-to-add-a-defaultfallback-radius-policy&#34; aria-label=&#34;Heading self-link&#34;&gt;&lt;/a&gt;&lt;/h2&gt;&#xA;&lt;p&gt;When designing your RADIUS architecture in EZRADIUS, it&amp;rsquo;s important to consider what happens when a user&amp;rsquo;s authentication request does not match any of your defined access policies. By default, if no access policies match an authentication request, the request will be rejected and the user will not be authenticated to the network. However, you may want to have a default or fallback access policy that matches any incoming authentication request with a valid certificate or valid Entra ID credentials, even if the request does not meet the specific conditions of your other access policies. This default/fallback policy can be used to ensure that users are still able to authenticate to the network and get some level of access, even if their device or user attributes do not match any of your more specific access policies.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How-To: Control RADIUS Policies and Behavior Based on Entra ID Group Membership</title>
      <link>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/match-radius-policy-on-entra-group-membership/</link>
      <pubDate>Fri, 24 Apr 2026 12:00:00 -0700</pubDate>
      <guid>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/match-radius-policy-on-entra-group-membership/</guid>
      <description>&lt;h2 data-toc-text=&#34;Overview&#34; id=&#34;overview---how-to-match-radius-policies-on-entra-id-group-membership&#34;&gt;Overview - How to Match RADIUS Policies on Entra ID Group Membership&lt;a class=&#34;td-heading-self-link&#34; href=&#34;#overview---how-to-match-radius-policies-on-entra-id-group-membership&#34; aria-label=&#34;Heading self-link&#34;&gt;&lt;/a&gt;&lt;/h2&gt;&#xA;&lt;p&gt;In this pattern, you can use a user or device&amp;rsquo;s Entra ID group membership to control authentication behavior. A common use case of this is to place devices in different VLANs based on their Entra ID group membership. This approach allows you to segment your network based on user or device attributes, enhancing security and ensuring that different groups of users or devices have access to the resources they need while restricting access for others.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How-To: Control RADIUS Policies and Behavior Based on Intune Device Compliance</title>
      <link>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/match-radius-policy-on-intune-compliance/</link>
      <pubDate>Fri, 24 Apr 2026 12:00:00 -0700</pubDate>
      <guid>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/match-radius-policy-on-intune-compliance/</guid>
      <description>&lt;h2 data-toc-text=&#34;Overview&#34; id=&#34;overview---how-to-match-radius-policies-on-intune-device-compliance&#34;&gt;Overview - How to Match RADIUS Policies on Intune Device Compliance&lt;a class=&#34;td-heading-self-link&#34; href=&#34;#overview---how-to-match-radius-policies-on-intune-device-compliance&#34; aria-label=&#34;Heading self-link&#34;&gt;&lt;/a&gt;&lt;/h2&gt;&#xA;&lt;p&gt;In this pattern, you can use a device&amp;rsquo;s Intune compliance state to control authentication behavior. A common use case of this is to place compliant devices in a separate VLAN than non-compliant devices. This approach allows you to segment your network based on device compliance, enhancing security and ensuring that compliant devices have access to the resources they need while restricting non-compliant devices.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How-To: Control RADIUS Policies and Behavior Based on SSID Name</title>
      <link>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/match-radius-policy-on-wireless-ssid/</link>
      <pubDate>Fri, 24 Apr 2026 12:00:00 -0700</pubDate>
      <guid>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/match-radius-policy-on-wireless-ssid/</guid>
      <description>&lt;h2 data-toc-text=&#34;Overview&#34; id=&#34;overview---how-to-control-authentication-and-access-policies-based-on-ssid-name&#34;&gt;Overview - How to Control Authentication and Access Policies Based on SSID Name&lt;a class=&#34;td-heading-self-link&#34; href=&#34;#overview---how-to-control-authentication-and-access-policies-based-on-ssid-name&#34; aria-label=&#34;Heading self-link&#34;&gt;&lt;/a&gt;&lt;/h2&gt;&#xA;&lt;p&gt;In this pattern, you can use EZRADIUS to control RADIUS policies and behavior based on the SSID name that a device is connecting to. This approach allows you to create different access policies for different SSIDs, enabling you to segment your network and apply specific authentication and authorization rules based on the network a device is connecting to. For example, you could have one SSID for corporate-owned devices that requires certificate-based authentication and places devices in a secure VLAN, and another SSID for BYOD devices that uses Entra ID authentication and places devices in a separate VLAN with more restricted access.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How-To: Control RADIUS Policies and Behavior for BYOD/Personal Devices</title>
      <link>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/radius-for-byod-devices/</link>
      <pubDate>Fri, 24 Apr 2026 12:00:00 -0700</pubDate>
      <guid>https://www.keytos.io/docs/cloud-radius/cloud-radius-reference-architectures/radius-for-byod-devices/</guid>
      <description>&lt;h2 data-toc-text=&#34;Overview&#34; id=&#34;overview---how-to-control-radius-policies-and-behavior-for-byodpersonal-devices&#34;&gt;Overview - How to Control RADIUS Policies and Behavior for BYOD/Personal Devices&lt;a class=&#34;td-heading-self-link&#34; href=&#34;#overview---how-to-control-radius-policies-and-behavior-for-byodpersonal-devices&#34; aria-label=&#34;Heading self-link&#34;&gt;&lt;/a&gt;&lt;/h2&gt;&#xA;&lt;p&gt;In this pattern, you can have separate RADIUS policies for BYOD and corporate-owned devices. This approach allows you to segment your network and VLANs based on device ownership, enhancing security and ensuring that corporate-owned devices have access to the resources they need while restricting personal BYOD devices.&lt;/p&gt;&#xA;&lt;h3 data-toc-text=&#34;Ownership Evaluation&#34; id=&#34;how-are-devices-evaluated-for-ownership&#34;&gt;How Are Devices Evaluated for Ownership?&lt;a class=&#34;td-heading-self-link&#34; href=&#34;#how-are-devices-evaluated-for-ownership&#34; aria-label=&#34;Heading self-link&#34;&gt;&lt;/a&gt;&lt;/h3&gt;&#xA;&lt;p&gt;There are a couple different ways to separate BYOD devices from corporate-owned devices in EZRADIUS, depending on how you want to evaluate device ownership:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
