# Separate RADIUS proxy forwarding from user authorization

> Which responsibilities belong on an NPS proxy rather than the destination RADIUS server?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-177-separate-radius-proxy-forwarding-from-user-authorization/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-08T18:14:14+00:00
- Modified: 2026-09-08T18:26:31+00:00
- Last reviewed by DSE: 2026-09-08
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Which responsibilities belong on an NPS proxy rather than the destination RADIUS server?

## Potentially affected

Administrators designing NPS as a RADIUS proxy.

## DSE recommendation

Create a request-flow diagram with the incoming client, applicable connection request policy, chosen remote group, and final authorization owner.

## Article

## Source facts

An NPS proxy receives RADIUS connection requests and forwards them to other RADIUS servers for processing. Microsoft says the proxy does not perform connection authorization, so it does not need network policies for that role. The documented proxy can be a domain member or a standalone server and does not require AD DS registration to read user dial-in properties. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-proxy).

## Applicability

Confirm whether the planned NPS instance is acting as a proxy, a RADIUS server, or both in the actual design. Identify the access devices, destination server groups, and the team responsible for the final access decision. Keep forwarding configuration distinct from authorization policy.

## DSE recommendation

Create a request-flow diagram with the incoming client, applicable connection request policy, chosen remote group, and final authorization owner. Review the network path and shared-secret handling for each hop without placing secrets in the diagram. Ask the receiving administrator to confirm which server will make the access decision. Include an unmatched request and an unavailable destination in the acceptance plan.

## Verification

Send approved test requests through the proxy and compare the selected destination with the routing design. Check the response at the access device and the authorization result at the destination server. Preserve timestamps that allow the two teams to correlate the transaction. Resolve unexpected local handling or forwarding before production use.

## Official references

[Microsoft Learn: Plan NPS as a RADIUS proxy](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-proxy). Source reviewed September 8, 2026.

## Primary reference

- Name: Plan NPS as a RADIUS proxy
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-proxy
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Separate RADIUS proxy forwarding from user authorization,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-177-separate-radius-proxy-forwarding-from-user-authorization/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.