SASE_RFI.6.22.26.docx

Request for Information Secure Access Service Edge (SASE) Solution Note: This is not a bid or request for proposal. This Request for Information (RFI) is issued solely for information and planning purposes only and does not constitute a solicitation. Responses to the RFI will not be returned. Responses to this RFI are not an offer and cannot be accepted by the State to form a binding contract.

Questions concerning this RFI should be directed via email to UW Madison Purchasing Manager Caleb Hall caleb.hall@wisc.edu.

RFI Issued Date: June 23, 2026 Questions Due: June 30, 2026 RFI Due Date: July 14, 2026 by 2:00 PM CT

Email questions and completed RFI responses to caleb.hall@wisc.edu.

Request for Information (RFI): Secure Access Service Edge (SASE) Project Title: Enterprise Secure Access Service Edge (SASE) Enablement

Table of Contents

Request for Information (RFI): Secure Access Service Edge (SASE) Project Title: Enterprise Secure Access Service Edge (SASE) Enablement

1. Introduction and Purpose The University of Wisconsin–Madison is soliciting information regarding an enterprise SASE solution supporting federated governance, Zero Trust, and regulated research environments.

2. Scope of Requirements The university seeks a cloud-native SASE platform delivering integrated networking and security services across users, devices, and applications.

3. Technical and Functional Requirements A. Administrative Hierarchy and Federated Management

1. Describe your support for hierarchical or multi-tenant organizational structures.

2. Describe how global security policies can be enforced as non-overridable by departmental administrators.

3. Describe delegated administrative roles, scopes, and RBAC granularity.

4. Describe policy inheritance, conflict resolution, and override behavior.

5. Describe how logs, configurations, and analytics are isolated across tenants.

6. Can different departments define policies without seeing each other’s apps?

7. What usage events increase cost Without explicit admin action?

8. Are new features automatically licensed when enabled?

9. How does pricing change with temporary population spikes (students, contractors)?

10. Are logs, analytics, or retention metered separately?

11. How are Point of Presence (PoPs) or regions priced over time?

12. What skill sets are required after deployment?

13. What changes require vendor support or escalation?

14. Typical troubleshooting workflows (who looks first?)

15. Mean time to resolution with vendor involvement?

16. How does your solution help support unmanaged devices?

17. On endpoint devices does your solution require an agent install? When the user does not have admin access to install anything, how are those devices handled?

B. Core SASE Capabilities

18. Identify which SASE capabilities are native, integrated, or roadmap.

19. Describe Secure Web Gateway (SWG) inspection and policy enforcement.

20. Describe Firewall-as-a-Service (FWaaS) architecture and policy model.

21. Describe Zero Trust Network Access (ZTNA) capabilities and app-level access controls.

22. Describe CASB, DLP, DNS Security, IPS, sandboxing, and SSPM features.

23. Describe management-pane architecture; number of consoles required, single management plane/policy engine, unified data lake and API support for automation and integration with existing IT tooling.

24. How are policies tested before deployment?

25. Are policies ordered, evaluated, or merged, and how is conflict resolved?

C. Networking and Connectivity

26. Describe native SD-WAN functionality and supported transports.

27. Describe support for remote users, branch sites, campuses, and data centers.

28. Describe traffic optimization, QoS, and failover behavior.

29. Describe integration with existing WAN or network infrastructure.

30. Research often involves multi-terabyte datasets. Does the SASE PoP architecture throttle high-bandwidth, long-lived flows?

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?

D. Identity, Access, and Device Context

32. Describe supported identity providers and authentication standards.

33. Describe user provisioning and lifecycle management.

34. Describe device posture assessment and trust signals.

35. Describe conditional access logic and continuous risk evaluation.

36. Describe supported access for unmanaged or BYOD endpoints.

37. Describe support for IoT/OT, lab devices, research instrument networks and nonhuman identities (machine/NHI) including onboarding, inventory, and access controls.

38. How does your solution enforce identity-based access for nonhuman identities and how policies differ from human accounts.

39. How do multiple IdPs or tenants coexist?

40. Can access policies degrade safely instead of failing open or closed?

41. Describe your integration with SecureW2.

E. Security Policy Controls

42. Describe application segmentation and least-privilege enforcement.

43. Describe session-level controls (clipboard, file transfer, printing).

44. Describe TLS/SSL inspection and certificate handling.

45. Describe logging, alerting, and SIEM/SOAR integrations.

46. Describe protections against lateral movement and insider threats.

47. How is privileged access treated differently from standard users?

F. Availability, Performance, and Scalability

48. Describe your global PoP architecture and traffic routing model.

49. What features are GA today vs. GA only for certain regions or PoPs?

50. Can performance issues be attributed to your PoP vs. the SaaS provider?

51. What happens when users are far from the nearest PoP (rural, global research)?

52. Describe SLAs for availability, latency, and packet loss.

53. Describe resiliency, redundancy, and disaster recovery capabilities.

54. How are stale sessions handled during identity outages?

55. Describe visibility into user experience and application performance.

56. Describe any scale limits, quotas, or licensing constraints.

57. What features shown in demos are off by default or require premium licensing?

58. For third-party collaborators using unmanaged devices, provide typical architectures (RBI, secure browser, reverse proxy) and onboarding/credentialing processes suitable for research and teaching collaborators.

59. How many policy objects are realistically supported before performance degrades?

60. What forensic data is not available due to architecture?

61. Ability to reconstruct full user sessions

62. Role of Vendor during customer security incidents.

G. Compliance, Data Protection, and Accessibility

63. Describe support for FERPA, HIPAA, NIST 800-171, CUI, and FedRAMP-aligned use cases.

64. Describe data inspection, encryption, key management, and residency controls.

65. Describe secure data deletion, retention, and legal hold capabilities.

66. Describe WCAG 2.1 / Section 508 accessibility conformance and testing.

67. Explain log routing, retention, and where inspection/logs/data (including DLP matches and UEBA telemetry) are stored; provide options for logical vs physical data separation and sovereign/private SASE deployments.

68. Can inspection be selectively disabled per app, user, or data classification?

69. Where exactly does TLS decryption occur - PoP, region, country?

4. Vendor Questionnaire A. General Information

1. Provide an overview of your organization, including history and ownership.

2. Identify primary technical and contractual contacts.

3. Provide URLs for product documentation, support, and training.

4. Describe your experience supporting higher education or regulated research environments.

5. Provide at least three reference customers similar in size or complexity.

6. Describe your product roadmap for the next three years and your five-year vision.

7. Describe your release cycle and customer communication approach.

8. Describe your cloud platform(s), data center locations, and data residency guarantees.

9. Describe your patching, maintenance, and SLA model.

10. What is your incident notification timeline?

11. Who leads incident response- Vendor, customer, or shared?

12. Can costs be allocated or broken out by user departments?

13. Are there minimum commitments or sustained-use discounts?

14. Are there data egress charges?

B. Accessibility

15. Does your solution conform to WCAG 2.1 (A/AA) and Section 508 requirements?

16. Has the solution been tested with assistive technologies? If so, which?

17. Describe your accessibility testing and QA methodology.

18. How are accessibility regressions prevented during upgrades?

19. Describe known accessibility limitations and remediation plans.

20. Describe how accessibility issues are reported and addressed.

5. Submission Instructions

Send a completed response via email by 2:00 p.m. July 14, 2026, to:

Caleb Hall, Purchasing Manager UW Madison caleb.hall@wisc.edu

Include in your response:

· Executive summary.

· Completed responses to Section 3, including references requested in Section 4.A.5.

· Architecture diagrams.

· Product roadmap for 2026–2027.

· Detailed pricing and licensing, including add-ons and higher education discounts.

6. Anticipated Timeline The anticipated schedule for this RFI process is as follows:

RFI Issued June 23, 2026 Questions Due June 30, 2026 Information Due by July 14, 2026 2:00PM (CDT) The University reserves the right to modify this schedule.

7. Questions

Questions regarding this RFI should be submitted via email by June 30, 2026, at 2:00 pm (CDT) to:

Caleb Hall, Purchasing Manager UW Madison Caleb.hall@wisc.edu

8. Disclaimer

This Request for Information is issued for informational and planning purposes only. It does not constitute a solicitation for proposals and does not obligate the University to issue a subsequent procurement document or enter into any agreement. Responses to this RFI are not an offer and cannot be accepted by the State to form a binding contract.

The University reserves the right to:

• Modify or cancel this RFI at any time

• Request additional information from respondents

• Conduct interviews with respondents

• Use information received to structure a future procurement process

The University is not responsible for any costs incurred by respondents in preparing responses to this RFI.

image2.png image1.png