Security has been a growing focus across our last few releases, and for good reason: it's a moving target, and the landscape is shifting faster than usual right now. AI capability is advancing quickly — and while mainstream models like GPT and Claude carry real guardrails, increasingly capable open-source models don't carry the same constraints, and they're lowering the bar for what a motivated bad actor can attempt. That makes this a good moment to take stock. This update brings together new and existing security capabilities in Kademi, along with our recommended practices for keeping your programs secure — read through each section below, and use the linked documentation to dig into whichever topics apply to your program.
Partner Account Security: Lock down admin access
Admin console access is one of the highest-value targets in your Kademi setup. There are two supported paths to strong login security: two-factor authentication (2FA) on individual accounts, or Single Sign-On (SSO) through your identity provider. Either path should be enforced for every admin profile, including client admins, and can be paired with a strong password policy at the admin-group level for extra protection.
Suggested checklist:
- Confirm every admin profile has 2FA enabled, or is provisioned via SSO
- Check for admin accounts still active for employees who've left, and disable them
- Set a recurring reminder (every 6 months) to review the admin account list
- Consider enforcing strong password requirements at the admin-group level
Documentation:
Participant Account Security: Know who's on your program, and how they get in
Program security starts with making sure the people who join actually belong there. The process looks different depending on whether your program is invite-only or open access, but either way you need active oversight of who's signing up and periodic reviews of who's still active. Beyond registration, participant account security can be strengthened with tools like IDP rules, a secure password policy, and 2FA — though with participants there's often a real trade-off between simplicity and security, so this is worth designing carefully rather than switching on. Reach out to the Kademi team if you'd like to talk through what fits your program.
Suggested checklist:
- Review your registration process, and confirm who has oversight
- Clear out stale or unused participant accounts on a regular cadence
- Enforce a secure password policy for participant accounts
- Get advice from Kademi on using IDP rules as an extra security filter
- Get advice from Kademi about pros and cons of enforcing 2FA for participants
Documentation:
Program Security: Design for your program's actual risk
Not all programs carry the same fraud risk, and your controls should scale with it. Cash and cash-equivalent rewards — real-time prepaid or gift cards, for example — are meaningfully more attractive to bad actors than merchandise, so the more cashable your payout, the tighter your registration and redemption controls need to be. For cash programs, add a review step at redemption as well as registration (see Participant Account Security for the mechanics), and make sure your CAPTCHA threshold reflects the higher risk.
Suggested checklist:
- Identify whether your program offers cash/cash-equivalent rewards, and treat that as higher risk than merchandise
- For cash/cash-equivalent programs, add a hold-for-review step before payouts are released
- Review your CAPTCHA minimum score — the platform default is 0.5; higher-risk programs may want it raised
- Confirm registration approval controls are in place (see Participant Account Security)
Documentation:
- View our Guide to CAPTCHA in Kademi
- View our guide on how to approve an order before the card exists
Fraud Prevention: Turn on a system that's already running
Every purchase, voucher redemption and signup is already being scored against eleven fraud rules built into the platform — nothing to install or switch on. Right now we're in a tuning phase: scores are being recorded so we can confirm the rules are accurate before anything is actually refused. Once we're confident in the scoring, we'll switch on refusing/blocking — and when we do, you'll be notified first, and you'll always be able to disable or adjust it for your program. Kademi's own response, once enabled, stops at refusing the transaction and notifying admins; blocking an address or disabling a profile is a separate, opt-in step configured through IDP.
Suggested checklist:
- Check whether your account has blocking switched on, or is only recording
- Review recent Fraud Events before changing any thresholds
- If one rule dominates every event, retune that rule rather than raising the overall threshold
- Turn blocking on once confident, and watch the Refused count
- Confirm the right people hold FraudViewer or FraudManager access
Documentation:
IDP Rules: Your global protection, personalised to your program
Every Kademi client sits behind an application-level request-filtering layer called IDP (Intrusion Detection & Prevention) — it works inside the application itself, seeing things a conventional firewall can't, and makes its decision before a request ever reaches your program. A shared global policy already runs for every client with no setup required, automatically blacklisting known attackers, throttling brute-force logins, and blocking known exploit patterns. That policy is deliberately generic, though, so we recommend personalising it — adding program-level rules like geo-blocking, or escalating repeated suspicious activity (including fraud scores) into a temporary block.
Suggested checklist:
- Understand that the global IDP policy is already protecting you, with no action required
- Review whether program-level rules (e.g. geo-blocking, custom velocity limits) suit your risk profile
- Talk to Kademi about building custom rules for your program — these are authored by hand, not self-service
- Talk to Kademi about escalating signals from Fraud Prevention into IDP blocking actions
Documentation: