A file transfer and secure email platform concentrates an organisation's most sensitive outbound and inbound content in one place, so the way it is configured, connected and retired matters as much as the product itself. This guide explains how to harden a Kiteworks deployment: authentication and MFA policy, admin roles, custom API applications and their tokens, syslog and SIEM integration, DLP and threat scanning hooks, and the appliance and network baseline. It also covers the customer-side lifecycle lesson from the legacy Accellion File Transfer Appliance (FTA), which reached end of life on 30 April 2021: retire file transfer platforms on schedule and migrate them cleanly. It is written for Kiteworks administrators, security engineers and identity teams. For the discipline as a whole, see the Managed File Transfer (MFT) Security Guide.
This is an independent guide from NHI Mgmt Group, based on Kiteworks' public documentation and product security pages as of November 2026. It is not sponsored or reviewed by Kiteworks. Product features change, so confirm settings against Kiteworks' current documentation.
Key takeaways
- Enforce MFA for every user population. Kiteworks documents that admins can require MFA for all users and choose methods by role or criteria, including TOTP apps, RADIUS, PIV/CAC smart cards, SMS and email.
- Treat custom API applications as service accounts. Each one holds a Client Application ID and Client Secret Key shown once and fixed after creation, so scope it tightly, restrict it by user and IP, and set short token lifetimes.
- Use the admin roles, not shared admin accounts. Kiteworks describes eight default admin roles plus custom roles; map each admin job to the narrowest one.
- Send syslog to your SIEM from day one. Kiteworks states that its syslog exports all data and administrative events, including logins, privilege changes and DLP or threat scan failures.
- Plan the end of life before you need it. The legacy FTA product's end of life on 30 April 2021 is a reminder to track support dates for every file transfer platform and to finish migrations, including credential and integration clean-up.
How identity and access work in Kiteworks
Kiteworks product pages describe SAML 2.0 and Kerberos single sign-on (naming Okta, Ping, ADFS and Azure among providers), directory integration with LDAP, Active Directory and Entra ID, and multi-factor options: TOTP authenticator apps, RADIUS, PIV/CAC, SMS one-time passcodes through providers such as Twilio, email-based second factor, and certificate authentication for SFTP. Kiteworks' MFA article states that admins can require MFA for all users and configure methods by user role or other criteria, for example RADIUS for internal users on the corporate network and SMS or email for external partners.
| User population | Recommended sign-in (our recommendation) | Why |
|---|---|---|
| Employees | SAML SSO to your IdP, with the IdP enforcing phishing-resistant MFA | Joiner, mover and leaver changes flow from the directory |
| Administrators | SSO plus PIV/CAC or TOTP enforced in Kiteworks | Admin sessions reach policy, keys and logs |
| External partners and recipients | Kiteworks accounts with TOTP preferred, SMS or email second factor where TOTP is impractical | Partners rarely federate; keep a second factor on every login |
| SFTP clients and automation | Certificate (key) authentication for SFTP, custom API application for API workflows | No shared passwords in scripts |
External users are the largest population on most file sharing platforms. Kiteworks pages describe least-privilege defaults and role-based permission sets for feature and resource access. Set expiry on external accounts and shared links, and review dormant external users every quarter, removing any with no sign-in for 90 days (our recommendation). See the Secure File Sharing Guide and the Phishing-Resistant MFA Guide.
Admin roles and privileged access
Kiteworks' zero-trust architecture page states that the platform has eight default admin roles plus custom roles. Confirm the current role names and their permissions in Kiteworks' admin documentation, then map them to jobs.
- Separate platform administration from helpdesk work: password resets, user unlocks and quota changes should not carry rights to change authentication policy, encryption settings or syslog destinations.
- Restrict the highest admin role: keep it to two or three named people, each with strong MFA, and use it only for platform changes (our recommendation).
- Use custom roles for compliance staff: auditors and DPOs need read access to reports and logs, not configuration rights.
- Release rights for DLP holds are privileged: Kiteworks describes designated admins releasing DLP false positives. Limit that right to a small reviewed group, because each release lets a flagged file leave.
- Review admin assignments quarterly and after any change of team, with evidence kept for audit.
See the Privileged Access Management Guide.
Integrations, API tokens and service accounts
Workflows such as onboarding automation, archiving and line-of-business uploads use Kiteworks custom applications built on its REST API. Kiteworks' developer documentation describes OAuth 2.0 flows including Authorization Code (acting for a signed-in user) and server-side flows for trusted applications (described as JWT or signature-based authorisation, which lets a trusted client obtain tokens on behalf of users). Kiteworks advises using the server-side and user credential flows only for trusted applications. Confirm the flows available in your version in Kiteworks' current documentation.
| Setting on the custom application | What it controls | Baseline (our recommendation) |
|---|---|---|
| Authorization flow | How the app obtains tokens | Authorization Code for user-facing apps; server-side flow only for a vetted internal service |
| API scopes | Which endpoints the app can call | Only the scopes the workflow uses |
| Access token lifetime | How long a token is valid | Shortest the workflow tolerates, for example one hour |
| Enable refresh token / Refresh token lifetime | Whether and how long tokens renew without sign-in | Off for server-side jobs that can re-authenticate; bounded when on |
| Access Control: Allowed Users | Which users the app may act for | Specific users or a service user, not Allow All Users |
| Access Control: Allowed IPs | Source addresses permitted | Your integration hosts' addresses or CIDR ranges, not Allow All IPs |
| Redirect URI | Where authorisation codes are sent | Exact HTTPS URI owned by your organisation |
| Mobile settings (PIN, Remote Wipe, Open-In list) | Data handling in mobile apps | PIN on, Remote Wipe on, Open-In limited to approved apps |
- Record and vault the credentials at creation: Kiteworks states the Client Application ID and Client Secret Key are displayed once and cannot be changed after creation. Store them in a secrets manager immediately.
- Rotate by replacement: because the ID and secret are fixed, rotation means creating a new application with the same scopes, cutting the workflow over and then disabling the old one. As our recommendation, do this at least annually and whenever someone with access leaves.
- One application per workflow: separate apps keep scopes small and make a compromised secret easy to revoke without breaking unrelated jobs.
- Signature keys are secrets too: where a signature or JWT flow uses a key you generate or supply, keep the private key in a vault or HSM and never in scripts.
See the Service Account Security Guide and the API Key Management Guide.
Logging and detection
Kiteworks' integration page states that its syslog exports all data and administrative events, including file movements and access, access control and privilege changes, user onboarding and offboarding, login successes and failures, and anti-virus, ATP and DLP scan failures. Named SIEM targets include Splunk (with a Kiteworks Splunk app), IBM QRadar, ArcSight and LogRhythm, and the zero-trust page describes continuous feeds by syslog and Splunk Forwarder.
| Signal | What to alert on |
|---|---|
| Admin privilege change | New admin role assignment, custom role edited, especially outside change windows |
| Authentication policy change | MFA requirement relaxed, SSO settings edited, new authentication method enabled |
| Login failures | Bursts per account or source IP; successful login after many failures |
| Custom application activity | New application created, scopes widened, Allowed IPs set to all |
| Bulk download or share | One user or app downloading or sharing far above baseline |
| Scan failures and releases | DLP or ATP failures and every DLP release by an admin |
| Syslog gap | No events from the appliance for longer than your normal quiet period |
Metrics (our suggested set): percentage of active users with MFA enforced (target 100%); number of holders of the top admin role (target two or three); custom applications with an owner, restricted IPs and a credential under 12 months old (target 100%); external accounts dormant over 90 days (target zero); mean time to review a DLP release. See the SIEM Log Source Onboarding Checklist.
Hardening baseline
Kiteworks describes its deployment as a hardened virtual appliance: a stripped-down Linux operating system hardened to CIS guidelines, unused ports and SSH access disabled by default, an embedded network firewall, web application firewall and intrusion detection, embedded anti-malware, and updates applied with a single click, with update packages cryptographically verified. In a tiered deployment only the web service tier sits in the DMZ and clustered nodes communicate over an encrypted channel. Product pages state TLS 1.3 in transit and AES-256 at rest, with customer-held keys and HSM options including Thales SafeNet Luna Network HSM and AWS KMS.
| Area | Customer-side setting | Baseline |
|---|---|---|
| Updates | Apply Kiteworks updates | Within your critical patch window; subscribe to Kiteworks security notices |
| Network placement | Tiered deployment | Only the web tier in the DMZ; application and storage tiers internal |
| Remote access | SSH and unused ports | Keep the defaults (disabled); open only with a change record and close after |
| Encryption keys | Customer-managed keys, HSM integration | HSM or KMS for regulated data; document key ownership and recovery |
| Outbound content | DLP via ICAP | Scan outgoing files and block on failure for regulated data types |
| Inbound content | ATP scanning (Check Point SandBlast natively, ICAP-compatible ATP) | Quarantine failing files and notify security |
| Sharing | Link and account expiry | Expiry on every external share; no permanent public links |
| Logging | Syslog to SIEM | On, monitored for gaps |
See the Data Loss Prevention (DLP) Guide and the Cryptographic Key Management Guide.
Lifecycle lessons from the legacy FTA
Kiteworks announced on 25 February 2021 that its legacy FTA software, described as a 20-year-old product, would reach end of life on 30 April 2021, with no renewals after that date and migration help to Kiteworks at no additional cost. The customer-side lessons apply to any file transfer platform:
- Track support dates: record end of support for every file transfer and sharing product in your asset inventory, with an owner and a migration plan at least 12 months ahead (our recommendation).
- Find every instance: legacy appliances often live with business units, partners or DR sites. Search DNS, certificates and firewall rules for old hostnames, and ask partners which endpoints they still send files to.
- Migrate identities, not just files: recreate users from the directory, re-enrol MFA, and rebuild integrations as new scoped API applications rather than copying old service credentials.
- Revoke what the old platform held: rotate any credentials it stored or used (directory bind accounts, SMTP relay accounts, partner SFTP keys) once cut-over is complete.
- Decommission completely: remove DNS records, firewall rules and certificates, and wipe or destroy storage under your disposal policy.
See the Technology End of Life Policy Template.
Common misconfigurations
- MFA enforced for staff but not partners: external accounts sign in with a password alone. Apply a second factor to every population.
- Custom applications with Allow All Users and Allow All IPs: a leaked client secret then works from anywhere for anyone. Restrict both.
- Credentials not vaulted at creation: the secret is displayed once and ends up in a ticket or script. Store it in a secrets manager before closing the dialog.
- Shared admin login: one admin account used by several people defeats role separation and audit. Use named accounts and roles.
- Syslog configured but unmonitored: events reach the SIEM with no alerts or gap detection.
- Old platform left running after migration: a retired appliance keeps its DNS name, credentials and data. Finish decommissioning.
Framework mapping
| Kiteworks control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Risk it reduces |
|---|---|---|---|
| MFA enforcement, SSO | IA-2, IA-8 | PR.AA-01 | Account takeover with stolen passwords (ATT&CK T1078 Valid Accounts) |
| Admin roles, external account review | AC-2, AC-6 | PR.AA-05 | Excess admin rights and dormant partner access |
| Custom application scopes and IP limits | IA-5, AC-6 | PR.AA-01 | Misuse of a leaked client secret (ATT&CK T1528 Steal Application Access Token) |
| TLS, encryption at rest, HSM keys | SC-8, SC-12, SC-28 | PR.DS-01, PR.DS-02 | Interception or theft of stored content |
| DLP and ATP scanning | SI-3, SI-4 | PR.DS-01 | Sensitive data leaving, malware arriving |
| Syslog to SIEM | AU-2, AU-6 | DE.CM-03 | Undetected misuse |
| End-of-life tracking | SA-22 | ID.AM-02 | Running unsupported software |
Practitioner checklist
- Require MFA for all users and choose methods by population, with PIV/CAC or TOTP for admins.
- Federate employees through SAML SSO and keep partner accounts on expiring, MFA-protected logins.
- Map admin jobs to Kiteworks' default or custom admin roles and limit the top role to two or three people.
- Create one custom API application per workflow with minimum scopes, Allowed Users and Allowed IPs set.
- Vault each Client Secret Key at creation and replace applications on a schedule.
- Send syslog to your SIEM and alert on admin, authentication and application changes.
- Connect DLP and ATP scanning and restrict who can release DLP holds.
- Keep SSH and unused ports closed and apply Kiteworks updates within your patch window.
- Record end-of-support dates for every file transfer platform and finish decommissioning after migration.
Standards and references
- Kiteworks Developer: Custom applications
- Kiteworks Developer: Create custom applications
- Kiteworks: Hardened virtual appliance
- Kiteworks: Security integrations
- Kiteworks: Zero-trust architecture security functions
- Kiteworks: Multi-factor authentication and CISA Secure by Design
- Kiteworks: Accellion announces end of life for legacy FTA product
Related NHI Mgmt Group resources: Managed File Transfer (MFT) Security Guide · Secure File Sharing Guide · Service Account Security Guide · Technology End of Life Policy Template