72-PJTH26087 Questions & Answers Addendum 3.pdf

STATE OF NORTH CAROLINA

UNIVERSITY OF NORTH CAROLINA AT WILMINGTON

Purchasing Services

IMPORTANT RFP ADDENDUM

Date Addendum Issued: July 2, 2026

RFP NUMBER: 72-PJTH26087 COMMODITY: Web Application Firewall (WAF)

ADDENDUM NUMBER: THREE (3) USING AGENCY: UNCW

PURCHASING AGENT: Justin Hewett OPENING DATE/TIME: July 20, 2026/ 2:00 PM ET

INSTRUCTIONS:

This Addendum forms a part of the RFP Documents and modifies the Contract Documents with amendments and additions noted below:

I. Question and Answers:

1. Section 1.0, p. 4 — Current Environment The RFP references "11 to 14 services" today and a minimum of "18 web applications/services" at target state (Section 5.0). Can UNCW confirm the exact count of internet-facing FQDNs to be protected at go-live, and clarify whether the gap between current (11–14) and target (18) represents net-new services to be onboarded during this engagement or already-existing services not currently behind the F5

Answer: There will be 11 total services to be migrated. While these services will be public facing, some will need IP access restrictions.

2. Section 5.0, p. 13 — Current Environment Can UNCW provide an approximate count of existing F5 iRules in production, along with a categorization of their functions (e.g., header manipulation, routing logic, content rewrite, authentication, redirects)? This significantly impacts migration effort estimation, as iRules typically require manual redesign rather than direct conversion when migrating to cloud-native WAF platforms.

Answer: There are approximately 5-8 irules in production. Please see the response to question 24 for granular irule information.

3. Section 5.0, p. 13 — Current Environment The RFP references F5 LTM/AWAF/ASM modules. Is F5 APM (Access Policy Manager) also currently in use for any of the in-scope services? If so, should authentication and access policy functions currently handled by APM be migrated to the new WAF solution or to Microsoft Entra Conditional Access?

Answer: The APM is not in use

4. Section 5.0, p. 14 — Cloud Environments The RFP lists OCI, AWS, and Azure as example cloud environments. Can UNCW confirm which cloud platform(s) currently host the in-scope applications today, and which platform(s) are anticipated to host them at the conclusion of this engagement?

Answer: All resources are currently on prem. We just need to know that the platform has the capability to work on our cloud platforms that include OCI and Azure.

5. Section 5.0, p. 14 — Load Balancing Web Application Firewall and Load Balancing are distinct functions that are often licensed and priced separately by cloud WAF vendors. Can UNCW clarify whether a single integrated platform is preferred for both WAF and load balancing, or whether the State is open to a primary WAF service paired with cloud-native load balancing (e.g., Azure Load Balancer, AWS ALB) for backend distribution?

Answer: Yes, the Load balancing platform and WAF platform need to be a single solution.

6. Section 5.0, p. 14 — Geographic Load Balancing The RFP requires the solution "distribute traffic across multiple geographically diverse sites, supporting weighted or prioritized load balancing per service." Can UNCW clarify whether this refers to Global Server Load Balancing (GSLB / DNS-based traffic steering across regions) or to load balancing across multiple backend servers within a single region?

Answer: The system is currently load balancing across multiple backend servers, however the system needs to be capable of load balancing across different regions.

7. Section 5.0, p. 14 — Entra Conditional Access The RFP requires the WAF to "allow backend applications to enforce Microsoft Entra Conditional Access." Can UNCW clarify the intended enforcement model: (a) WAF acts as a SAML/OIDC service provider and enforces CA policies directly, (b) WAF passes authentication headers through to backends which enforce CA, or (c) WAF logs authentication decisions made by an upstream identity provider?

Answer: The WAF would pass the SSO traffic to the backend application.

8. Section 5.0, p. 15 — SIEM Integration The RFP requires log forwarding to "Splunk and/or Rapid7 InsightIDR." Can UNCW clarify which platform is the primary system of record, the deployment model (Splunk Cloud vs. Splunk Enterprise on-prem; Rapid7 cloud vs. on-prem collector), and the preferred ingestion method (HTTP Event Collector, syslog, S3 bucket, or vendor-native connector)?

Answer: Rapid7 Insight IDR is the primary. It is a cloud as well as on prem.

However, we want to use cloud. Our preferred ingestion method is a vendor native connector. If that doesn't exist, we can connect via HTTP with a custom connector, preferably a connector that’s vendor supported.

9. Section 5.0, p. 14 — mTLS Passthrough The RFP requires "mutual TLS (mTLS) passthrough for backend services where end-to-end client certificate authentication is required." Approximately how many of the 18 in-scope services require mTLS passthrough, and can UNCW describe the use case (e.g., API-to-API authentication, device certificates, partner integrations)?

Answer: At current there are no services that leverage MTLS however we would like for the platform to have this capability in the event of a future service needing MTLS.

10. Section 5.0, p. 14 — Post-Quantum Cryptography The RFP states cryptography "must be in line with TLS 1.3 and PCQ. If not currently quantum resistant, this will need to be on the roadmap." Can UNCW clarify whether post-quantum cryptography (PQC) is required at contract award, required within a specific timeframe (Year 1, Year 2), or required only as documented vendor roadmap commitment?

Answer: Documented as being on the vendor roadmap

11. Section 5.0, p. 15 — Project Deadlines The RFP requires the overall project be completed by December 1, 2026, with project start no later than September 1, 2026, and the proof of concept completed within 3 weeks. Migrating 18 services in approximately 10 weeks post-POC is aggressive. Will UNCW consider a phased go-live where the WAF is in production for a defined first wave of services by December 1, with remaining waves completed under an extended timeline?

Answer: The December 1 deadline has been determined based on the end of support date on our current hardware, the projects we have scheduled for later in the month, and exams beginning in December. We cannot shift our go live date back beyond December, as our current hardware is end of support January 1, 2027.

12. Section 4.2, p. 10 — HUB Participation The RFP references a 10% HUB participation goal. For an engagement of this scope where the primary deliverable is a vendor-hosted SaaS subscription (the WAF platform itself), is HUB participation evaluated based on the total contract value including the SaaS subscription, or only on the professional services and implementation portion of the contract?

Answer: HUB participation is based on the total contract value.

13. Section 4.9, p. 13 — Insurance Requirements Section 4.9 indicates the default insurance coverage tier is "up to $1,000,000." Can UNCW confirm the specific minimum coverage amounts required for General Liability, Professional Liability (E&O), Cyber Liability, and Workers' Compensation, so vendors can confirm policy adequacy prior to proposal submission?

Answer: Please refer to section 15 of the North Carolina General Terms & Conditions found at the following link:

https://www.doa.nc.gov/north-carolina-general-terms-and-conditions-5-2025/open

14. Section 7.0, Attachment A — Pricing Attachment A includes line items for "Additional Traffic Charges" (per GB/TB) and "Additional Request Volume Charges" (per million requests). Can UNCW provide an estimate of current and anticipated peak traffic volumes (requests per second, bandwidth GB/month) for the 18 in-scope services? Accurate sizing significantly impacts the proposed pricing tier.

Answer: We have the following data for the last 234 days from the existing device pair:

ClientSide Traffic – Bits in 5.7T – Bits out 16.73T. Please see the response to question 15 for additional traffic metrics.

ServerSide Traffic – Bits in 4.9T – Bits out 17.21T

15. Technical Spec, pg. 14-15 What are the bandwidth requirements for the applications?

Answer: Between 9-1-25 and 4-22-26 We saw the following peak usage on the link that serves all of the virtual servers:

Inbound 264Mbps Outbound 265Mbps

95th percentile usage during that period is as follows:

Inbound 1.5Mbps Outbound 1.6Mbps

We would like this to be adjustable in the event that we need to pay more or if we would like to pay less.

16. Technical Spec, pg. 14-15 Is there a need for Integrated AI/Machine Learning Support?

Answer: No

17. Technical Spec, pg. 14-15 What are the requirements around supporting wildcard certificates?

Answer: The solution does need to support wildcard certificates and will predominantly use wildcard certs.

18. Technical Spec, pg. 14-15 How will the backend servers need to be reached? IP or DNS?

Answer: We would like the flexibility for both options.

19. Technical Spec, pg. 14-15 What type of load balance method(s) need to be supported?

Answer: Round Robin, Ratio

20. Technical Spec, pg. 14-15 What ACME service is being used? Let's Encrypt Support needed?

Answer: ACME services are not currently in use, but we are actively exploring options.

Vendors may, at their discretion, include a description of the services supported by their proposed solution.

21. Technical Spec, pg. 14-15

Will Splunk/Rapid7 be publicly accessible from the Internet?

Answer: Yes

22. Technical Spec, pg. 14-15 What is an example of a custom WAF rule?

Answer: If HTTP payload contains string “malicious_Payload” -> Drop Connection

23. Technical Spec, pg. 14-15 What are the requirements to performing health checks against the backend servers? What particular protocols do you need to support to determine whether a server is alive and responded successfully to the health-check?

Answer: We would like to use a TCP half open check and possibly an https check to a known static page where possible.

24. Current Environment, pg. 14 Some more niche functionality Is performed by the irule scripting language provided by the F5. Examples of this niche functionality include modifying/inserting headers as well as making forwarding decisions based on the header content.

What is the exact functionality that the iRule scripting provides?

Answer: Please see the irules listed below:

1. /Common/websocket_selective_http_disable when HTTP_REQUEST { if { [string tolower [HTTP::header Upgrade]] contains "websocket" }{ HTTP::disable

2. /Common/_sys_https_redirect when HTTP_REQUEST { HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]

3. /Common/hostname_redir when HTTP_REQUEST { if { [string tolower [HTTP::host]] equals "something.domain.edu" } { HTTP::redirect "https://somethingelse.domain.edu[HTTP::uri]"

4. /Common/removeCSPMInjectionForAll when HTTP_RESPONSE { AVR::disable_cspm_injection

5. /Common/insert_x_real_ip

HTTP::header insert X-Real-IP [IP::remote_addr]

6. /Common/site-blockhostname if { [HTTP::host] equals "something.subdomain.domain.edu" } { log local5. "Blocked hostname: [HTTP::host]" reject

7. /Common/application_console_redirect when HTTP_REQUEST { if {([string tolower [HTTP::host]] equals "application.domain.edu:3780")}{ HTTP::header replace Host "application.domain.edu"

25. Current Environment, pg. 14 Can you provide an example of the iRule itself?

Answer: In DNS we have a record to point towards *.subdomain.domain.edu since there is large list of subdomains. One Irule drops connections if they are trying to connect to specific.subdomain.domain.edu while allowing all others. Please see the answer to question 24 for more irule details.

26. Current Environment, pg. 14 What other distinct use cases that iRule provides that is a hard requirement?

Answer: Please see the answer to question 24 for more irule details.

27. Current Environment, pg. 14 What is the expected outcome of these rules and are you open to alternative methods to accomplish a similar functionality?

Answer: The expected outcome is to replicate the functionality of the Irules. We are certainly open to alternative methods assuming it provides the same functionality.

28. Current Environment, pg. 14 What are the requirements around HTTP/3 support? Do you require HTTP/3 between the end user and the WAF, HTTP/3 between the WAF and the origin server, or both?

Answer: We don’t require http3 support at this time, however we would like for the platform to have the option to use it going forward.

29. Training Requirement, pg. 15 Is the "practice configuration" tenant expected to be always available or adhoc if and when needed for a specified/short period of time?

Answer: This practice environment was intended to exist for the duration of any training that our staff were enrolled in.

30. Implementation , pg. 16 What will be the state of the on-premises F5 during the migration?

Answer: It will remain up through the conclusion of the migration.

31. Implementation , pg. 16 Will the F5 be online in case of roll out?

Answer: It will remain up through the conclusion of the migration.

32. Implementation , pg. 16 What mechanism can be used to swing traffic back to the on-premise F5 in event of roll back?

Answer: DNS will be pointed back to the original VIP on the F5 device

33. 2.7 Proposal Contents, RFP pg. 9, Item c.

To clarify, would you like us to include the entire 23-page RFP attached with our response? Are we allowed to submit any other material or a response on our own paper?

Answer: Suppliers are allowed to provide additional material along with the 23-page RFP.

34. 4.7 Questions to Vendors – Vendor Product and Experience, RFP pg. 13, Question 1.

We would like to protect the privacy of our client references and their contact information. Is there an acceptable approach for submitting the required references while safeguarding this information, such as providing contact details upon request or through another approved method?

Answer: It is a requirement of the proposal for references to be provided.

35. 4.7 Questions to Vendors – Project Approach and Timeline, RFP pg. 14, Question 13.

Question 13 requests that offerors "Explain [their] approach to meeting the requirements listed in Section X." However, we were unable to locate a Section X within the solicitation. Could you please clarify the intended section or provide the correct reference for this response?

Answer: This is located in Section 5 Specifications and Scope of Work

36. RFP Section 5.0, Page 14 - Current Environment Can UNCW provide an example or summary of the current F5 BIG-IP configuration, including virtual servers, pools, pool members, health monitors, certificates, SSL profiles, persistence profiles, iRules, and ASM/AWAF policies?

Answer: There are 11 virtual servers that have their own pools and AWAF policies. Health monitors are currently done via TCP half open checks and ICMP. There are no persistence profiles in use.

There are three Client SSL Profiles and two different certificates used across the virtual servers.

Please see the response to question 24 for detailed irule information.

37. RFP Section 5.0, Page 14 - Current Environment Can UNCW provide an example or summary of the current F5 BIG-IP configuration, including virtual servers, pools, pool members, health monitors, certificates, SSL profiles, persistence profiles, iRules, and ASM/AWAF policies?

Answer: There are 11 virtual servers that have their own pools and AWAF policies. Health monitors are currently done via TCP half open checks and ICMP. There are no persistence profiles in use.

There are three Client SSL Profiles and two different certificates used across the virtual servers.

Please see the response to question 24 for detailed irule information.

38. RFP Section 5.0, Page 14 - Current Environment Does UNCW already have an OCI tenancy and landing zone established for this project, including compartments, IAM groups/policies, networking, logging, tagging, and governance standards, or should vendors include design and setup of these foundational OCI components in scope?

Answer: OCI is out of scope for this work, we just want to ensure the solution will be compatible with services in OCI if we choose to go that route in the future

39. RFP Section 5.0, Page 14 - Current Environment Can UNCW provide an application inventory for each in-scope service, including FQDN, backend servers/IPs, ports, protocols, health check paths, certificate details, authentication method, application, business criticality, and required cutover approach?

Answer: There are 11 virtual servers that have their own pools and AWAF policies. Health monitors are currently done via TCP half open checks and ICMP. There are no persistence profiles in use.

There are three Client SSL Profiles and two different certificates used across the virtual servers.

Please see the response to question 24 for detailed irule information. More information to be provided to the winning vendor.

40. RFP Section 5.0, Page 14 - Current Environment For each application, should vendors assume separate WAF/LB/DNS configurations for production, non-production, test, and POC environments? If so, how many environments should be included in the initial scope?

Answer: Yes, separate for each. There are 11 applications total including both test and prod

41. RFP Section 5.0, Page 14 - Current Environment Can UNCW provide an example for F5 health monitor configuration for services, including monitor type, path, expected response code/content, interval, timeout, retry behavior, and failover criteria?

Answer: At current we only use an ICMP monitor along with a TCP port check. We would however like to check a static page with http protocol wherever possible.

42. RFP Section 5.0, Page 14 - Current Environment For each load-balanced service, can UNCW identify whether session persistence is required and specify the current persistence method, such as source IP, cookie, SSL session, or custom iRule-based persistence?

Answer: Session persistence is not in use

43. RFP Section 5.0, Page 14 - Current Environment Are there target latency, throughput, availability, or performance requirements for each protected application, and should vendors include performance testing against these targets as part of implementation?

Answer: Applications currently behind the WAF have different business criticalities, so some performance requirements would be different for each. Overall, UNCW's expectation is that the proposed solution will maintain application performance at a level that does not introduce noticeable or material degradation to end-user experience under normal operating conditions. UNCW expects a dynamic and resilient environment that can ensure 99.99+% uptime, and UNCW expects RCA updates when downtimes occur. When possible, UNCW would like to have the responding vendors produce documentation on performance metrics for the past year.

44. RFP Section 5.0, Page 14 - Current Environment Can UNCW provide estimated current daily or monthly log volume from the F5/WAF environment, and expected retention requirements for WAF, access, audit, and configuration logs?

Answer: There are roughly 500MB - 1.5GB of logs generated daily by the F5 appliance. We will need the logs exported to our Splunk cloud service where they will be retained for 90 days.

45. RFP Section 5.0, Page 14 - Current Environment How many certificates are currently in use across the F5 environment?

Answer: 2 total certificates

46. RFP Section 5.0, Page 14 - Current Environment Does UNCW expect vendors to support vulnerability scanning, penetration testing, security validation, or third-party security testing before production cutover? If so, what tools, scope, and remediation expectations should be assumed?

Answer: UNCW has no expectation of security scans, pen testing or third part security testing prior to cutover. However, we do want the vendor to ensure that the services are working as expected prior to cutover. Verify things like IP whitelisting and WAF signature blocking are working appropriately. As far as methods of testing, we want to lean on the chosen vendor for their expertise in this area.

47. RFP Section 5.0, Page 14 - Current Environment How many iRules are currently in use, and can UNCW provide representative examples of iRules used for header modification, header insertion, URL/path logic, and header-based forwarding decisions?

Answer: Please refer to the response in question 24 for detailed irule information.

48. RFP Section 5.0, Page 14 - Current Environment Are any current F5 iRules performing advanced functions beyond header manipulation and forwarding decisions, such as redirects, authentication logic, URL rewriting, cookie manipulation, rate limiting, or custom security checks?

Answer: Please refer to the response in question 24 for detailed irule information.

49. RFP Section 5.0, Page 14 - Current Environment Does UNCW expect a like-for-like migration of existing F5 behavior, or is redesign/reimplementation using cloud-native services acceptable where it provides equivalent or improved functionality?

Answer: Assuming the functionality is the same, the second option is perfectly fine.

50. RFP Section 5.0, Page 14 - Current Environment Are current F5 AWAF/ASM policies expected to be migrated directly, or should the vendor design new WAF policies using the proposed platform's managed and custom rule capabilities?

Answer: New WAF policies using the platforms managed rules and custom rules used sparingly where needed.

51. RFP Section 5.0, Page 14 - Current Environment Are there applications that currently depend on F5-specific persistence methods, such as source IP affinity, cookie persistence, SSL session persistence, or custom persistence logic?

Answer: No

52. RFP Section 5.0, Page 14 - Current Environment Are there known applications that are sensitive to WAF inspection, TLS termination, proxy headers, or source IP handling and should be prioritized for early testing?

Answer: There is one application that has been most severely impacted by DOS attacks. We will most likely prioritize the migration of this application first.

53. RFP Section 5.0, Page 14 - Technical Specifications The RFP states the current environment includes between 11 and 14 services, while the technical specifications require WAF protection for a minimum of 18 web applications/services. Can UNCW confirm the expected number of applications/services to be protected at go-live? And a high-level architecture of the applications protected by the WAF/LB?

Answer: Should be 11 at go live. We have plans to migrate more applications at a future point so we want to ensure we have capacity.

54. RFP Section 5.0, Page 14 - Technical Specifications Can UNCW provide expected traffic volumes for each protected application, including monthly request count, peak requests per second, average and peak bandwidth, typical response size, and expected geographic distribution of users?

Answer: Please refer to the response in question 14 for aggregate throughput details

55. RFP Section 5.0, Page 14 - Technical Specifications For the five services requiring load balancing with at least two backend servers each, can UNCW identify the applications and provide backend topology details?

Answer: At current no production services will need load balancing capabilities. We do want this setup for our test environment though to use as a guide in the event that we load balance something in the future. These test servers will be a couple of Apache servers that will be used for troubleshooting.

56. RFP Section 5.0, Page 14 - Technical Specifications Are all 18 protected applications externally/publicly accessible, or are some internal-only applications that still require WAF protection?

Answer: 7 of the 11 apps are public facing, we will need IP whitelisting in front of the remaining 4

57. RFP Section 5.0, Page 14 - Technical Specifications Are APIs included in the 18 protected applications/services, and if so, are there specific API security requirements such as schema validation, JWT validation, throttling, or API-specific logging?

Answer: No APIs just web applications

58. RFP Section 5.0, Page 14 - Technical Specifications Should proposed sizing account only for applications known at contract start, or should vendors include growth assumptions for additional applications during the initial contract term?

Answer: Vendors should include growth assumptions for additional applications during the initial contract term.

59. RFP Section 5.0, Page 15 - DNS CNAME Routing The RFP states traffic must route via DNS CNAME records configured on customer-managed DNS servers. Can UNCW confirm which DNS platform currently manages the uncw.edu zones?

Answer: MCNC

60. RFP Section 5.0, Page 15 - DNS CNAME Routing Will UNCW permit vendors to recommend DNS TTL reductions prior to cutover to support faster rollback if needed?

Answer: Yes.

61. RFP Section 5.0, Page 15 - Geographic Load Balancing Does UNCW require active-active routing across geographically diverse sites, or is active-passive regional failover acceptable?

Answer: Active passive should be acceptable

62. RFP Section 5.0, Page 15 - Geographic Load Balancing For geographically diverse load balancing, should routing be based on user geography, origin health, weighted distribution, primary/secondary priority, latency, or a combination of these methods?

Answer: There shouldn't be any geographically diverse applications in the migration. We just want to ensure that the platform is capable of doing this in the future where we would use a combination of these methods.

63. RFP Section 5.0, Page 14 - Multi-cloud and On-Prem Protection Are all backend origin sites currently on-premises, or will some origin services be hosted in OCI, AWS, Azure, or other cloud environments during the contract term? Please list the cloud service providers where the UNCW workloads currently reside.

Answer: All resources in scope are currently on prem. UNCW has cloud environments in OCI, Azure, and AWS.

64. RFP Section 5.0, Page 14 - Multi-cloud and On-Prem Protection Should vendors assume public internet connectivity from the WAF service to backend origins, or does UNCW prefer private connectivity where available?

Answer: Public Internet Connectivity

65. RFP Section 5.0, Page 14 - SSL Automation Can UNCW clarify the preferred certificate authority and certificate lifecycle process currently in use?

Answer: At current we are doing manual certificate renewals but we are currently exploring ACME-based certificate options prior to the severe shortening of public cert expiration dates.

66. RFP Section 5.0, Page 15 - ACME Certificate Management The RFP requires support for ACME-based certificate management. Is integration with Let's Encrypt, Certbot, or another ACME-compatible CA acceptable?

Answer: We are currently exploring ACME-based certificate options. Can the vendor supply what ACME-compatible CAs they support?

67. RFP Section 5.0, Page 15 - ACME Certificate Management Does UNCW require the proposed platform itself to natively support ACME, or is automation through scripts, APIs, or third-party ACME clients acceptable?

Answer: UNCW does not require the proposed platform to natively support ACME, provided that certificate automation can be achieved through vendor-supported methods. The primary requirement is that the solution be reliable, maintainable, and fully supported by the vendor, including the ability for UNCW to obtain assistance for implementation, troubleshooting, and ongoing operation. Total automation without administrator intervention is preferred.

68. RFP Section 5.0, Pages 14-15 - Certificate Management Are wildcard certificates currently used for *.uncw.edu, or does each protected service use an individual certificate?

Answer: Most services use a wildcard certificate, while one additional service uses it's own certificate.

69. RFP Section 5.0, Pages 14-15 - Certificate Management Are backend certificates currently issued by a public CA, internal CA, or self-signed?

Answer: Public CA

70. RFP Section 5.0, Page 14 - SSL Automation The RFP states automated certificate replacement for backend servers is a plus. Should this be treated as an optional scored enhancement?

Answer: Yes.

71. RFP Section 5.0, Page 14 - TLS 1.3 and PCQ The RFP references TLS 1.3 and PCQ. Can UNCW clarify PCQ?

If PCQ is not currently available in the proposed solution, is a published vendor roadmap sufficient to satisfy this requirement?

Answer: Post quantum cryptographic suites that will stop quatum computing from decrypting traffic.

This needs to be on the roadmap at a minimum.

72. RFP Section 5.0, Page 14 - HTTP Protocol Support The RFP requires support for HTTP/1.0, HTTP/1.1, HTTP/2.0, and HTTP/3. Is HTTP/3 mandatory at go-live, or is roadmap support acceptable?

Answer: Roadmap support for http3 is acceptable

73. RFP Section 5.0, Page 14 - HTTP Protocol Support Are there current applications or clients known to require HTTP/3, or is HTTP/3 included as a forward-looking requirement?

Answer: A forward looking requirement

74. RFP Section 5.0, Page 14 - HTTP Protocol Support Is HTTP/2 required only on the client-facing side, or also between the WAF/load balancer and backend servers?

Answer: both

75. RFP Section 5.0, Page 14 - Current Environment Are there any non-HTTP/S workloads currently handled by F5 that are in scope for this migration?

Answer: no

76. RFP Section 5.0, Page 14 - WAF Threat Signatures Does UNCW expect WAF policies to begin in monitoring/detection mode before moving to blocking mode?

Answer: Whatever methodology is easier to cut down on false positives either option is fine. We are wanting to lean on the chosen vendor for their guidance on this procedure.

77. RFP Section 5.0, Page 14 - WAF Threat Signatures What is UNCW's preferred tuning process for managed WAF rules before enforcement?

Answer: Have users who are familiar with the applications from a specific IP address or pool send legitimate traffic. Then whitelist what is being incorrectly blocked. We need the process of whitelisting the exceptions to be fast.

78. RFP Section 5.0, Pages 14-15 - Access Control Are there existing allowlists, blocklists, geofencing rules, or application-specific exceptions currently configured on F5 that should be migrated?

Answer: We will need the ability to do IP whitelisting for several of the applications.

79. RFP Section 5.0, Page 14 - URL Path Whitelisting Can UNCW provide examples of URL path allow/block rules currently in use?

Answer: We like to block the path to any sort of management UI from the internet. So a block would be something like server1.domain.edu/management/*

80. RFP Section 5.0, Page 15 - AND/OR Logic For the requirement involving AND/OR logic for source IP and URL path conditions, are there additional examples of expected rule logic beyond the /admin/management example?

Answer: if ip address is in CIDR range x.x.x.x/x AND URL starts with /path/to/something/ -> allow access \n else -> block /path/to/something*

81. RFP Section 5.0, Page 14 - False Positive Exceptions What is UNCW's expected approval process for creating WAF exceptions or disabling individual signatures due to false positives?

Answer: We plan to have users who are familiar with the applications from a specific IP address or pool send legitimate traffic. If something is being incorrectly blocked, we would then deem it necessary to create an exception.

82. RFP Section 5.0, Page 14 - False Positive Exceptions What is the expected service-level target for implementing emergency WAF exceptions during production incidents?

Answer: We would like for the user to see changes within 3 minutes of creating the exception

83. RFP Section 5.0, Page 15 - Independent WAF Policies

Should each application have a fully independent WAF policy, or are shared baseline policies with application-specific overrides acceptable?

Answer: We would prefer independent WAF policies per application.

84. RFP Section 5.0, Page 15 - Baseline Security Templates Are baseline security policy templates expected to align to specific frameworks or application types, such as OWASP Top 10, CIS, NIST, Java, .NET, or APIs?

Answer: We would like to receive best practice guidance from the selected vendor to meet the frameworks of NIST and CIS.

85. RFP Section 5.0, Page 15 - Bot and DDoS Can UNCW clarify whether the DDoS requirement is focused on Layer 7 application-layer DDoS, volumetric network-layer DDoS, or both?

Answer: Both

86. RFP Section 4.7, Page 12 - Bot and Automated Attack Mitigation Are credential stuffing, brute force login attempts, scraping, vulnerability scanning, or other automated attacks currently observed issues?

Answer: We do have an issue with bots scraping and this causing performance issues on the server side.

87. RFP Section 4.7, Page 12 - Bot and Automated Attack Mitigation Does UNCW require CAPTCHA, JavaScript challenge, device fingerprinting, rate limiting, behavioral bot detection, or other specific bot mitigation methods?

Answer: We certainly want to rate limit and have access to modern day bot mitigation techniques and

CAPTCHA.

88. RFP Section 4.7, Page 12 - Bot and Automated Attack Mitigation Should mitigation of bot activity be fully automatic, administrator-approved, or configurable per application?

Answer: Fully automatic would be preferred

89. RFP Section 5.0, Page 15 - Bot and DDoS Are there known legitimate automated clients, crawlers, integrations, or campus systems that must be allowlisted from bot controls?

Answer: None that we're aware of but we would like for the platform to offer this flexibility

90. RFP Section 5.0, Page 15 - SIEM Integration Which SIEM platform is authoritative for this project: Splunk, Rapid7 InsightIDR?

Answer: InsightIDR

91. RFP Section 5.0, Page 15 - SIEM Integration What log delivery method is preferred for SIEM forwarding: syslog, HTTPS endpoint, API pull, object storage export, or another method?

Answer: API pull is our first choice, Syslog and HTTP are acceptable as well.

92. RFP Section 5.0, Page 15 - SIEM Integration

Is near-real-time log forwarding required? If so, what is the expected latency target?

Answer: UNCW expects log forwarding to support timely operational monitoring, incident response, and security analysis. Vendors should describe the expected latency for log forwarding under normal operating conditions and identify any factors that may affect log delivery.

93. RFP Section 5.0, Page 15 - SIEM Integration The RFP states traffic logs must include full request headers. Are there privacy, security, or data minimization requirements that would restrict forwarding sensitive headers such as cookies, authorization headers, session tokens, or PII?

Answer: UNCW does not prohibit forwarding request headers required to meet the RFP requirements.

Additionally, UNCW requires that the vendor shall not retain copies of headers. Any header data must be provided exclusively to UNCW and shall not be disclosed to any third party, except law enforcement as required by law.

94. RFP Section 5.0, Page 15 - Logging What log retention period is required within the WAF/cloud platform before forwarding to the SIEM?

Answer: At least 2 days of logs on the WAF before forwarding to the SIEM

95. RFP Section 5.0, Page 15 - Configuration and Change Tracking Are configuration change logs required for all administrative actions, including policy changes, certificate changes, user access changes, and routing changes?

Answer: Yes.

96. RFP Section 5.0, Page 15 - SIEM Integration Should WAF logs include only blocked requests, or all inspected requests?

Answer: Ideally all inspected requests

97. RFP Section 5.0, Page 15 - Reporting Are reporting dashboards expected to be available inside the WAF platform, the SIEM, or both?

Answer: Both

98. RFP Section 5.0, Page 15 - Management SSO and MFA Which identity provider should be used for administrative access to the proposed solution: Microsoft Entra ID, DUO, or both?

Answer: Microsoft Entra ID

99. RFP Section 5.0, Page 15 - Management SSO and MFA Does UNCW require SAML, OIDC, or another federation protocol for administrative SSO?

Answer: SAML

100. RFP Section 5.0, Page 15 - Role-Based Access Control What administrator roles are required beyond read-only and full administrator?

Answer: Full admin and several iterations of read - only (depending on the group membership) is sufficient.

101. RFP Section 5.0, Page 15 - Role-Based Access Control

Are role-based permissions required at the application/service level, so teams can manage only assigned applications?

Answer: No

102. RFP Section 5.0, Page 15 - Management Access Should vendor/partner implementation staff be granted temporary federated access, local accounts, or access through another controlled process?

Answer: Vendor/partner access will be granted via "shoulder-surfing" or other controlled processes.

103. RFP Section 5.0, Pages 14-15 - Backend Security Should backend applications be reachable from the WAF using public IPs, private connectivity, VPN, FastConnect, or another method?

Answer: Public IPs

104. RFP Section 5.0, Pages 14-15 - Backend Security If backend services remain on-premises, does UNCW have existing network connectivity to OCI, or should the proposal include new connectivity design assumptions? E.g. public Site-to-Site VPN, dedicated FastConnect VPN

Answer: UNCW has an existing site-to-site tunnel to OCI.

105. RFP Section 5.0, Page 15 - WAF CIDR Ranges Should UNCW's backend firewalls block all traffic except approved WAF/origin CIDR ranges?

Answer: Yes, all inbound traffic on TCP port 443 needs to be isolated to the WAF CIDRs.

106. RFP Section 5.0, Page 15 - Backend IP Protection Are backend origins currently configured to accept only F5 source addresses, and will firewall or security-list changes be required during migration?

Answer: The backend origin servers themselves don't have this firewalling in place, however an upstream hardware firewall will block access to all incoming traffic except for traffic originating from the WAF service, so yes firewall changes will need to be made during this migration.

107. RFP Section 5.0, Page 15 - Custom Headers Are backend applications expected to use the original client IP through headers such as X-Forwarded- For?

Answer: Yes, additionally another application uses the X-Real-IP header.

108. RFP Section 5.0, Page 15 - Custom Headers Are there backend applications that require client IP preservation at Layer 3 rather than through HTTP headers?

Answer: At current all applications work successfully with either the x-forwarded-for or x-real-ip headers.

109. RFP Section 5.0, Page 15 - mTLS Which applications require mutual TLS today, and are they included in the initial migration scope?

Answer: None currently, we want the platform to be capable of supporting MTLS.

110. RFP Section 5.0, Page 15 - mTLS For services requiring mTLS, is the requirement for client-to-WAF mTLS, WAF-to-backend mTLS, full end-to-end client certificate passthrough, or certificate validation at the backend application?

Answer: No services require mTLS today, but we want the platform to be capable of supporting it.

111. RFP Section 5.0, Page 15 - mTLS Is TLS termination at the WAF/load balancer acceptable when mTLS is not required?

Answer: Yes, along with a TLS session between the WAF/LB and the origin server.

112. RFP Section 5.0, Page 15 - mTLS For true client certificate authentication, must the backend application inspect the original client certificate, or is WAF/LB validation with forwarded certificate attributes acceptable?

Answer: Either option is acceptable.

113. RFP Section 5.0, Page 15 - Web Application Acceleration Is web acceleration, caching, or compression required, or is it optional?

Answer: Optional but preferred where it won't cause problems, or significantly delay our ability to make an exception.

114. RFP Section 5.0, Page 15 - Web Application Acceleration Are any applications cacheable, or should the solution assume dynamic, non-cacheable content by default?

Answer: We would like guidance on this from the selected vendor. We would like to use these methods where they won't cause problems, or significantly delay our ability to make any WAF policy exceptions

115. RFP Section 5.0, Page 15 - Web Application Acceleration Are there application paths or content types that must never be cached?

Answer: We would like guidance on this from the selected vendor.

116. RFP Section 5.0, Page 15 - Web Application Acceleration Should compression be enabled globally, or evaluated per application during testing?

Answer: We would like guidance on this from the selected vendor.

117. 2.4 RFP SCHEDULE

Would UNCW consider extending the RFP deadline out two weeks for each vendor?

Answer: Yes.

118. 5.0 SPECIFICATIONS AND SCOPE OF WORK

For the readiness environment, what are the required outputs or deliverables needed for the assessment to be complete?

Answer: We believe that this question is asking about the readiness assessment of our environment.

If that is the case, then we would need to be provided any changes that need to be made to accommodate a migration from our current environment to the winning vendor's environment (including any proposed architectural changes), a timeline for the migration, and any estimates on incurred downtime for the migration.

119. 5.0 SPECIFICATIONS AND SCOPE OF WORK

When decommissioning F5, what are the details and expectations of the providing vendor versus responsibilities of the university IT team?

Answer: UNCW has no expectation of the vendor doing any work related to the decommissioning process of the F5.

120. Page 20, Five Year cost summary What managed services would be expected or recommended from UNCW or are managed services optional?

Answer: No managed services are expected.

121. Section 1.1 Contract Terms A three-year term contract is requested, but there's mention of two additional years to renew after the first year. Would UNCW issue a PO for three years (Billed upfront or annually?) or would UNCW issue a PO for one-year then issue a separate PO for each additional year thereafter?

Answer: UNCW will issue a PO for one-year then issue a separate PO for each additional year.

122. 5.0 SPECIFICATIONS AND SCOPE OF WORK

How many applications need protection for the next 3 to 5 years?

Answer: 11 applications will be protected by the WAF at go-live. Future growth will depend on many factors that can't be calculated at this time.

123. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there academic applications that have unique performance requirements? (admissions, registration, financial aid)

Answer: No.

124. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there seasonal spike to be considered?

Answer: Yes, some months will have higher traffic usage than others

125. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do the applications require load balancing?

Answer: At current no production services will need load balancing capabilities. We do want this setup for our test environment though to use as a guide in the event that we load balance something in the future. These test servers will be a couple of Apache servers that will be used for troubleshooting.

126. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there any applications that cannot be proxied through a cloud service due to regulatory guidelines?

Answer: At this time, UNCW has not identified a definitive list of applications that cannot be proxied through a cloud-based service due to regulatory, compliance, or operational constraints.

127. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do requirements include: API Security - discovery, alert, blocking, mitigation? (Application programming interface)

Answer: Yes

128. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What percentage of admin is API driven?

Answer: We estimate less than 20%.

129. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do requirements include: Bot protection beyond signature based?

Answer: Yes

130. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do requirements include: Account Takeover Protection?

Answer: No

131. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do requirements include: Client-Side Protection?

Answer: No

132. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do requirements include: Geo-Blocking?

Answer: Yes

133. 5.0 SPECIFICATIONS AND SCOPE OF WORK

How are certificates managed today? Automated cert renewal? Customer-managed certs?

Answer: Customer-managed certs

134. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do you use an internal Public Key Infrastructure (PKI) or public certificate authority?

Answer: Public CA

135. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there PQC requirements? (Post Quantum Encryption)

Answer: Just that PQC be on the vendor roadmap

136. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What SIEM is used? (Security Information and Event Management)

Answer: InsightIDR

137. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What logs are required? (access, security?)

Answer: UNCW requires the ability to generate and export standard WAF logs, including access, configuration, security/event, and audit logs. Vendors should describe the log types supported by the proposed solution and any limitations associated with log generation or export.

138. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What are SLA requirements? (Service Level Agreement)

Answer: UNCW has not established specific SLA requirements for this procurement. Vendors should describe their standard service level agreements, including support availability, response and resolution targets, escalation procedures, and any service commitments applicable to the proposed solution.

139. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Which cloud security environments are used - AWS, Azure, Google, other? (Amazon Web Services)

Answer: OCI, AWS, Azure

140. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there on-prem requirements and/or asks?

Answer: None.

141. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What is migration timeline?

Answer: See timeline provided in the RFP document.

142. 5.0 SPECIFICATIONS AND SCOPE OF WORK

From purchase, to install, to redirect to deployment, is there a timeline of expectation?

Answer: See timeline provided in the RFP document.

143. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Is there a single cutover expected?

Answer: No.

144. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Is there a preferred go-live date?

Answer: We must be completely migrated off of our current WAF before Jan 1, 2027. Our preferred drop dead date is December 1 2026, as that is before the start of finals.

145. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What is ingress and egress bandwidth?

Answer: See answer to question 14.

146. 5.0 SPECIFICATIONS AND SCOPE OF WORK

How do you measure bandwidth now?

Answer: NMS solutions using SNMP to poll F5 interfaces.

147. 5.0 SPECIFICATIONS AND SCOPE OF WORK

How do you measure bot traffic?

Answer: We don't measure bot traffic specifically today.

148. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do you know current peak throughput in RPS (requests per second?)

Answer: Our current infrastructure doesn't show peak throughput in requests per second format.

149. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Does your organization have an AI strategy that should be considered? (Artificial Intelligence)

Answer: No.

150. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there any AI-powered applications (LLM, chatbots, copilot, AI APIs) that will require protection?

(Large Language Models)

Answer: No.

151. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there security requirements specific to AI applications?

Answer: N/A

152. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Who are primary stakeholders (IT, Information security, procurement?)

Answer: ITS - specifically our networks, it security, and web application developer groups, and application owners.

153. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What is anticipated procurement and contract award timeline?

Answer: Proposals are due July 20, 2026 at 2:00 PM ET. Anticipated contract award date is August 19, 2026.

154. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Are there fiscal purchasing deadlines?

Answer: No.

155. 5.0 SPECIFICATIONS AND SCOPE OF WORK

Do you have a preferred billing structure - annual, upfront, multi-year?Do you require an MNDA?

(Mutual Non-Disclosure Agreement)

Answer: Annual billing structure is preferred. At this time, UNCW has not determined whether a Mutual Non-Disclosure Agreement (MNDA) will be required as part of this procurement.

156. 5.0 SPECIFICATIONS AND SCOPE OF WORK

What factors will ultimately determine the successful vendor selection?

Answer: The successful vendor will demonstrate the ability to provide a Web Application Firewall solution that best meets UNCW's functional and technical requirements while offering a streamlined deployment and management experience, a competitive and transparent total cost of ownership, and a proven implementation approach. The vendor should successfully complete the proof of concept, demonstrate compatibility with UNCW's

157. 5.0 SPECIFICATIONS AND SCOPE OF WORK

The RFP explicitly states a cloud-based WAF, and further states "Be cloud only – no on prem equipment, software, or VMs in the environment" - Would UNCW be open to a hybrid solution if agents are required and those agents may not be cloud-based agents?

Answer: UNCW strongly prefers a cloud only environment with no agents or on-prem requirements.

158. RFP Section 5.0, Page 13 - Project Deadlines Are all 18 applications expected to be migrated by December 1, 2026?

Is UNCW open to a phased migration where priority production applications are completed first and lower-risk applications follow?

Answer: We have 11 total applications that must be moved by Dec. 1 2026.

We are open to a phased migration.

159. RFP Section 5.0, Page 13 - Project Deadlines Are there blackout windows, academic calendar constraints, maintenance windows, or change freezes that vendors should account for?

Answer: Blackout dates: Finals for fall semester start after Dec. 1 and Thanksgiving holiday and weekend.

160. RFP Section 5.0, Page 13 - Project Deadlines Should services be delivered remotely, on-site, or hybrid? What about on-shore and off-shore resources?

Answer: Services can be delivered remotely. On-shore resources.

161. RFP Section 5.0, Page 16 - Implementation Requirements Does UNCW require on-site support during cutovers, or is…