Kademi environments sit behind protections that automatically block traffic patterns typical of automated security tooling - for example, requests to .php endpoints, which Kademi does not use. Source IPs that trigger these protections are blacklisted automatically.

If you have engaged a security firm to run a penetration test or vulnerability scan against your Kademi environment, we can temporarily whitelist their source IPs so the test can complete without being blocked.

This page explains what we need from you, how long it takes, and the conditions that apply.

What you need to send us

Raise a Support Request with our support team including all of the following:

1. The source IP addresses to be whitelisted (individual addresses or CIDR ranges).
2. A Rules of Engagement (RoE) or Scope of Work (SoW) document covering the engagement (see What we look for below).
3. The testing window - start and end date and time, expressed in NZST. The window must fall on New Zealand business days; we cannot schedule across weekends or New Zealand public holidays.

We cannot begin the review until all three are received.

Timing

If your test window is longer than 72 hours, please plan the engagement in blocks and raise a request for each block.

What we look for in the RoE / SoW

Either document is acceptable. We are not assessing the quality of your security engagement - we need enough detail to confirm the testing is authorised, scoped, and time-bound.

A Rules of Engagement document typically covers:

• The systems, applications, endpoints, and network areas that are in scope, and those explicitly out of scope.
• The agreed testing timeframes.
• The testing methods and techniques that have been approved.
• Communication protocols, including how critical findings will be reported and to whom.
• Named points of contact for both your organisation and the testing team.
• Confirmation that legal and compliance requirements have been addressed.

A Scope of Work document typically covers:

• The endpoints, systems, or applications to be tested.
• The objectives of the testing.
• Any exclusions intended to protect critical systems.
• The success criteria or deliverables for the engagement.

In practice, the RoE is the collaborative document that aligns expectations between you and your testers, while the SoW is the formal contractual record. Either one is sufficient for our purposes.

What happens next

1. Review. A member of our security team reviews your request within the 72-hour notice window.
2. Confirmation. Once approved, we schedule both the addition and the removal of the whitelist, and our support team confirms to you that the IPs are live.
3. Testing. Your testers run the engagement within the agreed window.
4. Removal. The whitelist is removed on the scheduled end date and our support team confirms this to you.

Conditions

Please make sure your testing team is aware of the following before the engagement begins.

• Excessive load results in immediate removal. If whitelisted traffic places excessive load on our infrastructure, we will remove the whitelist immediately and without prior notice, and notify you afterwards. This protects other clients sharing the platform. Please ask your testers to rate-limit automated scans accordingly.
• The 72-hour maximum is firm. We are not able to extend a whitelist beyond 72 hours or grant exceptions to it.
• Incomplete or late requests will not be processed. Requests missing documentation, falling outside business days, or submitted with less than 72 hours’ notice will be declined rather than expedited.
• The whitelist covers network access only. It does not authorise testing beyond the scope described in your RoE or SoW.

Questions

If you are unsure whether your engagement needs whitelisting, or whether your documentation will meet the requirements above, raise a Support Request before your planned start date and we will advise. It is always faster to check early than to have a request declined inside the notice window.