Amendment 2 SASE_RFI QAs.docx

SASE Q & A RFI Amendment #2 – Q & A Responses 7.8.26

1. Would you be willing to extend the RFI Response due date to August 4th?

The RFI Response due date has been extended to 7/21/2026, as announced in the First Amendment dated June 30, 2026.

2. Would you be willing to either extend the Q&A period for 2 weeks or offer a second Q&A period?

The Q& A Period was extended until July 3, 2026 as announced in the First Amendment dated June 30, 2026.

3. When do you anticipate having the Q&A responses available?

The Question period was extended to July 3, 2026. These responses are posted as soon as possible after the Question period close date.

4. Can you provide a user count and device per user count?

We will start with a small number of specific applications and their userbase (consisting of faculty, staff, and students) and will grow the number of applications, users, and devices over time.

5. Can you clarify whether the SASE solution that UW Madison may seek as a result of this RFI and any forthcoming RFP would be intended for faculty and staff only, or if the expectation is to extend SASE services and protections to all users, including the full student population?

We will start with a small number of specific applications and their userbase (consisting of faculty, staff, and students) and will grow the number of applications, users, and devices over time.

6. Is the desired model true logical multi-tenancy as in separate tenants per department with isolated data planes and log stores or centralized policy with scoped RBAC delegation and non-overridable global rules?

Centralized policy with scoped RBAC delegation and non-overridable global rules is preferred.

7. Roughly how many delegated administrative scopes do you anticipate, and is there an existing logical segmentation you want carried into SASE?

In addition to central IT, UW-Madison has more than 100 IT departments. Many school/college/division IT departments have sub departments.

8. Section 3.D references SecureW2, are you consuming it for certificate lifecycle and EAP-TLS onboarding, RADIUS, or as an IdP layer? Which functions should the SASE platform consume vs. Replace?

We are still in the planning phase for SecureW2. We expect to use SecureW2 for certificate lifecycle. It is hoped that a SASE platform will be able to consume SecureW2 managed certificates.

9. For nonhuman identities, do you mean service accounts/automation, or device identity for IoT/OT and lab instruments? These map to different controls.

We need to be able to control service accounts used in automation as well as loT and lab instruments.

10. Sections 3.C/F note multi-terabyte, long-lived research flows. Can you characterize peak per-site throughput, and whether you intend to steer those flows through cloud SASE inspection or bypass/split-tunnel them?

Internet connectivity is through Internet2, up to 100Gbps capacity. We are open to cloud inspection and split tunnel. Solution needs to support Jumbo frame connectivity and MTU negotiation across the Internet and split tunnel to campus resources. Our experience is that the service would be the traffic limiting factor (per TCP/IP session flow rate). Please provide your capacities for cloud inspection and bypass/split tunnel.

11. For legacy lab OS and agentless devices, are these on isolated segments today, and are you open to edge enforcement via an on-prem gateway, or strictly cloud-delivered agentless?

We are open to edge enforcement via an on-prem gateway.

12. For HIPAA/CUI workloads, must decryption and log storage remain in-region/in-country, or is selective no-decrypt per data classification acceptable?

Decryption and log storage must remain in the United States. Selective no-decrypt for some traffic is acceptable.

13. Do any workloads require a FedRAMP-authorized cloud service, and at what impact level?

FedRAMP Moderate could be in scope for some workloads.

14. To size accurately: total population, remote vs. on-campus split, number of sites, and expected seasonal variance?

We will start with a small number of specific applications and their userbase (consisting of faculty, staff, and students) and will grow the number of applications, users, and devices over time.

15. Is fixed-population all-inclusive licensing in scope, or do you require consumption-based pricing? We would like to see both.

16. Can you detail the number of users, term and use case (public apps, private apps VPN, etc.)? We will start with a small number of specific applications and their userbase (consisting of faculty, staff, and students) and will grow the number of applications, users, and devices over time.

17. Are there Specific requirements for data sovereignty and regional isolation (e.g., specific U.S. regions)? Also, are there requirements for data isolation between colleges and researchers? Data sovereignty currently needs to reside in the United States.

18. Which frameworks are mandatory vs. potential future-state (FERPA, HIPAA, NIST 800-171, CUI, FedRAMP, and/or GovRamp)? FERPA, HIPAA, and NIST 800-171 are initial; CMMC, FedRAMP Moderate, and NSPM-33 are future state frameworks.

19. Where are your current primary internet egress locations? Do you have a preference on Point of Presence location? Regionally redundant or US-Redundant? Primary egress location is likely Madison, WI, but we have users worldwide. No preference on PoP location or how redundancy is achieved. We use UWSYSNet for our POPs which could provide regional options.

20. What other locations are in scope for a SASE solution? Do you have global researchers or any non-US based entities that must be supported? Researchers do travel the globe, so we must be able to support them and their research.

21. What is the expected concurrent user number? (Students, Faculty, Guests/Contractors, Seasonal Spikes?)

We will start with a small number of specific applications and their userbase (consisting of faculty, staff, and students) and will grow the number of applications, users, and devices over time. The number of concurrent users can change, largely around the academic calendar (e.g., start of semester).

22. What existing cloud footprints does the UW have?

Azure, AWS, GCP. Many more SaaS providers.

23. What third-party vendors are currently in place for common integration points within a SASE solution.

· SIEM (Security Information and Event Management) Elastic

· Firewall Palo Alto Networks NGFW

· SOAR (Security Orchestration, Automation, and Response) N/A

· DLP (Data Loss Prevention) Spirion (data-at-rest-discovery), limited use of Purview

· EDR (Endpoint Detection and Response) Cisco Secure Endpoint

· IDP (Identity Providers, Azure AD etc.) MS AD, Entra ID, Shibboleth

24. How are non-human or headless entities authenticated and authorized today?

MS AD, Entra ID.

25. What are the largest DLP concerns as it relates to UW Data?

Authorized data access – ensuring that people only have access to the data they’re explicitly authorized to access. Initial focus on data tagging (both manual and automated) to facilitate safe use of AI tools, and data-in-motion controls for selected areas/enclaves (e.g. student records data should not leave designated SIS systems and tools; forthcoming CMMC enclave).

26. What critical on-prem applications require the same authorization framework as SaaS applications that will be under the purview of a SASE solution?

We will start with a small number of specific applications and their userbase (consisting of faculty, staff, and students) and will grow the number of applications, users, and devices over time (Common Scenarios: Legacy SQL Servers, DNS servers, Homegrown Apps etc.)

27. SDWAN: Are there multiple Data Center locations that will function as SD-WAN hubs. How are they interconnected?

Multiple data centers in Dane County and Milwaukee County. Connected via 100/400Gbps fiber.

28. Q40 - Section D: “can access policies degrade safely instead of failing open or closed”? Kindly elaborate on this; What does success look like from the UW’s perspective in this instance?

If a policy fails, it should fail closed while still having glass break access to fix issues.

29. Existing Infrastructure. Will you share what security and networking services are currently in place that the SASE solution is expected to integrate with or replace (e.g., existing SD-WAN edge devices, firewalls, or VPN concentrators)?

Yes, but not at this time. Currently we are not using SD-WAN.

30. Existing Infrastructure. Will you share details on your current technical environment, including your IDP/SSO solution, SaaS applications, enterprise NLMs in use, SIEM tool, datacenters and locations, firewalls, and cloud vendors/hyperscalers?

· SIEM (Security Information and Event Management) Elastic

· Firewall Palo Alto Networks NGFW

· SOAR (Security Orchestration, Automation, and Response) N/A

· DLP (Data Loss Prevention) Spirion (data-at-rest-discovery), limited use of Purview

· EDR (Endpoint Detection and Response) Cisco Secure Endpoint

· IDP (Identity Providers, Azure AD etc.) MS AD, Entra ID, Shibboleth

· Cloud Vendors: Azure, AWS, GCP. Many more SaaS providers

· Datacenters/Locations: Multiple data centers in Dane County and Milwaukee County

31. Endpoints and Users. How many internal users and managed endpoints do you have, and how many federated users and unmanaged endpoints are in scope?

We will start with a small number of specific applications and their userbase (consisting of faculty, staff, and students) and will grow the number of applications, users, and devices over time.

32. Endpoints and Users. Will you provide more context on temporary population spikes and the typical cycles or events that drive them?

The number of concurrent users can change, largely around the academic calendar (e.g., start of semester).

33. Endpoints and Users. Do you have an endpoint management or engineering team that packages and centrally deploys endpoint updates to user laptops and devices?

Yes. In addition to central IT, UW-Madison has more than 100 IT departments. Many school/college/division IT departments have sub departments.

34. Nonhuman Identities. Regarding nonhuman identities, can you clarify which identity types are in scope? For example, are you referring to AI agents, service accounts, devices, or other nonhuman identities? Additional scope detail would help us tailor our response to your environment.

AI agents, service accounts, devices, loT, and lab instruments are a good starting point.

35. SIEM and Log Volume. Do you intend to forward all SASE telemetry to an existing SIEM (e.g., Splunk, Sentinel), or are you open to utilizing the SASE platform's native data lake/analytics engines for primary investigation?

Yes, Elastic. We’re open to exploring native options.

36. SOC Operations. Does the university's internal SOC have the tooling and staffing capacity to scale alongside the new SASE monitoring demands, or are you looking for the SASE architecture to incorporate managed SOC/MDR options?

We are not looking for managed SOC/MDR options.

37. RFI Scope. Is this RFI intended to gather information on rollout/implementation services, vendor solutions, or both?

Both.

38. RFI Scope. Are you interested in learning more about AI/NLM security and visibility capabilities on the SASE roadmap?

Yes, but our primary focus is on existing functionality.

39. Facilities in Scope. How many branch offices do you have, and can you share any general location details?

https://www.wisc.edu/about/facts/

40. Compliance. Does CUI data include any defense-related data that should be considered under the Cybersecurity Maturity Model Certification regulatory framework?

Yes.

41. About the RFI named above, could you provide the details of the current contract providing these services such as contract #, value, and expiration?

There is no existing contract.

42. For WAN Connectivity (SD-WAN), what types of separation (if any) do you require? Completely separate wan fabric with separate gateways or logical separation through routing and security controls?

Separation is optional but not required. Currently we are not using SD-WAN.

43. For SSE - SWG/ZTNA: how many sub-tenants would you anticipate deploying? In addition to central IT, UW-Madison has more than 100 IT departments.

Many school/college/division IT departments have sub departments.

44. What is the current architecture of the existing WAN network? WAN Gateway and the types of circuits and bandwidth of the circuit.

UW Madison uses UWSysnet as its WAN provider connecting at multi-100Gbps for commercial Internet and at multi-400Gbps for research connectivity to Internet2. UWSysnet has regional peering relationships.

45. Transporting Multi-terabyte datasets were mentioned: what is the traffic pattern for these data— are they from on-premise device/user or remote user to SaaS cloud or to other facilities connected by WAN?

This would include bidirectional data streams; research data streams are transferred between remote users and both cloud and on-prem endpoints.

46. (1. Describe your support for hierarchical or multi-tenant organizational structures.) Regarding the requirement to describe support for hierarchical or multi-tenant organizational structures, should the solution be designed around a single account with delegated policy administration, or a managed multi-account / multi-tenant model to support UW–Madison’s federated campus requirements?

Managed multi-account/multi-tenant model to support UW–Madison's federated campus environment, enabling individual departments and administrative units to maintain autonomy while allowing for centralized governance, visibility, and policy oversight where appropriate. In addition to central IT, UW-Madison has more than 100 IT departments. Many school/college/division IT departments have sub departments.

47. (6. Can different departments define policies without seeing each other's apps?) For departments defining their own policies, does UW–Madison require application inventory to be completely hidden between departments, or should departments have non-editable visibility into applications outside their administrative scope?

Our preference would be for department admins to have non-editable visibility into applications outside their administrative scope. This would help prevent duplicate application onboarding efforts across the institution while maintaining appropriate administrative boundaries. Requests for access to applications owned by another department could continue to be reviewed and managed through Central IT.

48. (31. Many lab instruments run on legacy OSs (like Windows XP/7) that cannot host agents. Can the solution provide 'micro-segmentation at the edge' for these devices without requiring a local gateway?) For legacy lab instruments running operating systems such as Windows XP or Windows 7 that cannot host endpoint agents, can UW–Madison clarify what is meant by “without requiring a local gateway” in the context of edge micro-segmentation for legacy lab networks? 'without requiring a local gateway,'

UW–Madison means that the proposed micro-segmentation solution should not depend on deploying a dedicated physical or virtual security appliance within each laboratory network segment to enforce policy for legacy devices. For legacy instruments running operating systems such as Windows XP or Windows 7 that cannot support endpoint agents, the University prefers approaches where segmentation and access controls can be enforced through network-based mechanisms (e.g., switch integration, network-access controls, identity-aware networking, cloud-managed policy enforcement, or agentless discovery and profiling) rather than through a locally deployed gateway at each lab. Vendors should describe how micro-segmentation policies would be applied to unmanaged or devices where an agent cannot be installed and identify any infrastructure components required to support that capability.

49. (34. Describe device posture assessment and trust signals.) Regarding device posture assessment and trust signals, can UW–Madison clarify which posture checks, MDM integrations, certificate signals, and unmanaged/BYOD trust signals should be considered for UW–Madison’s environment?

MDMs include BigFix, Intune, Jamf, and Workspace ONE. Posture checks include, but are not limited to, [un]managed device, patch status, anti-malware protection status, encryption status, firewall status, backup status, DLP status, etc.

50. (44. Describe TLS/SSL inspection and certificate handling.) For TLS/SSL inspection and certificate handling, what certificate deployment methods, TLS/SSL inspection bypass categories, sensitive research exceptions, and logging expectations should be considered for UW–Madison’s environment?

We are open to solutions that adhere to industry best practices.