Secure Configuration Guide for Federal Deployments
1. Purpose, scope and terminology
This guide explains how to securely access, configure, operate and decommission the accounts that control an IronWiFi tenant, what the security-relevant settings do, and the tenant configuration IronWiFi recommends for agency deployments. Every item is configurable by the agency's own administrators in the IronWiFi console; none requires IronWiFi staff involvement. Where a recommendation depends on the agency's identity provider or network equipment, the dependency is named.
Top-level administrative account: The tenant owner: the operator account created with the tenant. In the console it holds the role named owner, carries every permission, and is the only account that can close the tenant.
Privileged account: A team member (any operator other than the owner) whose role grants any management permission. Roles are defined by the tenant from individual permission grants, so which accounts are privileged is the tenant's choice; section 3 lists the permissions and what each one can do.
2. Top-level administrative account: the tenant owner
2.1. Secure access
- Connect the tenant to the agency identity provider (SAML, or Okta) before any other administrative work, and enforce phishing-resistant multi-factor authentication at the identity provider for every operator, the owner included. Authentication is delegated to the identity provider; the platform does not weaken the provider's policy.
- Turn on the SSO-only setting for the tenant's email domain once single sign-on works. It refuses password sign-in for every operator in that domain, so a leaked or guessed password cannot bypass the identity provider.
- Until single sign-on is connected, enable a second factor on the owner account from the account settings page: a security key (FIDO2, phishing-resistant) by preference, otherwise the authenticator app; the email-code option is the weakest of the three. Use a unique password.
- Use the owner account for tenant-level administration only. Day-to-day work runs under team-member accounts holding a role, so that the owner's sessions are rare and reviewable.
- Keep the owner's mailbox under agency control: password reset and account notices are sent to it.
2.2. Secure configuration: settings only the owner can operate
| Setting | Security implication |
|---|---|
| Closing the tenant | Irreversible. Requires the owner's password and a reason (IronWiFi support staff acting on a tenant are exempt from the password check). Export reports and logs first; see section 2.4. |
| Every management permission | The owner holds all of them and delegates through roles. What the owner does not delegate stays owner-only, so keep the team members, roles and settings permissions with named administrators. |
2.3. Secure operation
- Review the team-member list and the roles assigned to it quarterly and after every personnel change.
- Review the tenant audit log for operator changes at least monthly.
- Issue API keys to named integrations only, one key each, bound to a role with the narrowest permissions, and revoke them on personnel change; keys are revocable individually. A key has no customer-set expiry (it stays valid for ten years unless revoked), so rotation is a deliberate step: create the replacement, move the integration, revoke the old key.
- Keep the identity-provider group that maps to console access as small as the roles require.
2.4. Secure decommissioning
- A team member: remove the operator from the team members page, revoke any API key that person created for an integration they alone ran, and remove the person from the identity-provider group that grants console access.
- The owner: the owner account is not removed while the tenant exists, and there is no self-service transfer. To hand it to another person, the current owner writes to [email protected], the monitored role mailbox published with IronWiFi's FedRAMP public information; IronWiFi confirms the request with the current owner before changing it.
- The tenant: export the reports and logs the agency must retain, revoke every API key, remove the tenant's RADIUS client entries from the agency's network equipment, then close the tenant from the account page, which asks the owner for the password and a reason.
3. Privileged accounts: settings by permission
Each row is a permission a role can grant. A team member holding it can operate the setting; the implication is what a mistake or a compromised account with that permission can do.
| Permission | Settings it operates | Security implication |
|---|---|---|
| Team members, roles | Inviting and removing operators; defining roles | Controls who can sign in and with what permissions. Over-delegation is privilege creep. |
| API keys | Creating and revoking API keys, each bound to a role | Mints programmatic credentials that carry the chosen role and do not expire on their own. |
| Authentication providers | The directories and identity providers used for password-based network authentication (Entra ID, Google Workspace, Okta, LDAP) | Pointing a network at the wrong provider admits the wrong population of users. |
| Billing | Subscription, payment method, invoices | Controls service continuity and who receives billing correspondence. |
| Settings | Tenant-wide settings, including single sign-on and the SSO-only setting | Turning single sign-on off, or SSO-only off, reopens password sign-in for the domain. |
| Networks | Networks, authentication methods, RADIUS clients (the agency's network equipment) with their shared secret or certificate | A device registered with a weak secret, or an authentication method weakened from certificate to password, lowers the assurance of every session on that network. |
| Certificates | The tenant certificate authority, SCEP enrollment, issuing and revoking device certificates | Revocation and enrollment policy decide which devices can authenticate with EAP-TLS. |
| Captive portals | Guest portals: fields collected, session limits, VLAN, expiry | Decides what guest data is collected and where guests land on the network. |
| Connectors | Third-party integrations such as CRM sync, off by default | An integration moves data outside the offering boundary. |
| Reports, shared files | Scheduled report delivery, exports | Exports carry authentication and accounting records; delivery targets must be agency-controlled. |
| Users, devices, vouchers, sharecodes, groups, user groups | End-user credentials, device records, guest vouchers and share codes, group policy | Creates or changes who can join the network and with which policy; vouchers and share codes are credentials. |
| Policies | Rules applied to authentication and sessions | Changes the conditions under which users and devices are admitted. |
| Access points | The access-point inventory, including automatic discovery | Decides which network hardware the tenant recognises and reports on. |
| Hotspot plans | Guest plans: time, data and bandwidth allowances | Loosens or tightens what guests can consume. |
| Organizational units | Scoping of operators, users and networks to units | Mis-scoping widens what an operator can see and change. |
| Outgoing emails | Sender identity and templates of emails the platform sends to end users | A changed template or sender is a phishing vector against the agency's own users. |
| Identity threat detection | Alert rules and delivery | Alerts routed to an unmonitored address are alerts nobody sees. |
The remaining permissions (tickets, fleets, vehicles, tariffs, tariff groups, translations, configurations, routes, attributes) cover other product areas; grant them by the same least-privilege rule.
4. Secure defaults at provisioning
- One owner account; sign-in by password, with a second factor (security key, authenticator app or email code) available for the owner to enable.
- No single sign-on until the agency's identity provider is connected, because the connection needs the agency's metadata; the SSO-only setting is off until then.
- No team members until one is invited; an invited team member holds only the role chosen at invitation.
- No API keys until one is created; a key carries the role chosen at creation and stays valid for ten years unless revoked. Not a secure default today: a key cannot be given a shorter expiry; IronWiFi records this with the gap below under SCG-CSO-SDF.
- Every third-party integration off; integrations are enabled per portal by the tenant only.
- Not a secure default today: the owner's second factor is not required at first sign-in. IronWiFi records this gap under SCG-CSO-SDF in its Security Decision Record, with the remediation date.
5. Operator access to the console
| Recommendation | Platform capability |
|---|---|
| Federate operator sign-in to the agency identity provider and make it the only sign-in path for the tenant. | SAML single sign-on per tenant, with an SSO-only setting that disables password sign-in for operators. |
| Enforce phishing-resistant multi-factor authentication at the identity provider for every operator. | Authentication is delegated to the identity provider under SSO; the platform does not weaken the provider's policy. |
| Assign operators the least role that covers their duties and review the operator list quarterly. | Role-based access control: tenant-defined roles built from individual permission grants. |
| Keep API access to named integrations with their own keys, one per integration; rotate on personnel change. | Per-tenant API keys, each named and bound to a role, revocable individually; no customer-set expiry, so rotation is a deliberate step. |
6. Network authentication
| Recommendation | Platform capability |
|---|---|
| Use certificate-based authentication (EAP-TLS) for agency-managed devices and enrol certificates through the agency's device management. | Cloud PKI with SCEP enrollment; EAP-TLS validated against the tenant certificate authority. |
| Where password-based EAP is unavoidable, bind it to the agency identity provider and restrict it to named networks. | PEAP and EAP-TTLS against Entra ID, Google Workspace, Okta or LDAP; per-network authentication provider selection. |
| Encrypt RADIUS traffic between network equipment and the platform. | RadSec (RADIUS over TLS) with per-tenant client certificates; conventional RADIUS remains available for equipment that cannot do RadSec. |
| Disable MAC-address-only authentication except for devices that support nothing else, and confine those to a dedicated VLAN. | Per-network authentication policy and VLAN assignment. |
| Reject authentication from network devices not registered to the tenant. | RADIUS clients are registered per tenant with their own shared secret or certificate. |
7. Guest and captive-portal access
| Recommendation | Platform capability |
|---|---|
| Keep guest networks on separate VLANs and apply session time limits and bandwidth policy. | Per-portal session duration, data and bandwidth limits, VLAN assignment on accept. |
| Collect only the guest attributes the agency needs and set an expiry for guest accounts. | Configurable portal fields; guest account expiry per portal. |
| Do not enable third-party lead-capture integrations on agency portals. | Integrations such as CRM sync are off by default and enabled per portal by the tenant only. |
8. Monitoring, logging and response
| Recommendation | Platform capability |
|---|---|
| Export authentication and accounting logs to the agency's own SIEM and retain them per agency policy. | Scheduled report delivery by signed link; REST API access to authentication, accounting and audit records. |
| Enable identity threat detection alerts and route them to the agency security operations mailbox. | Wi-Fi identity threat detection and response (ITDR) with alert delivery by email and webhook. |
| Review the tenant audit log for operator changes at least monthly. | Operator activity audit log per tenant. |
| Report suspected incidents affecting the agency's data to [email protected]; FedRAMP-reportable incidents are handled per the procedures recorded in the certification package. | Security contact published with the FedRAMP public information; FedRAMP Security Inbox monitored daily. |
9. Data handling
| Recommendation | Platform capability |
|---|---|
| Choose the platform region that matches the agency's data residency requirement when the tenant is created. | Regional tenancy; tenant data is stored in the selected region's database. |
| Prefer certificate-based methods so that no end-user password is stored by the platform. | EAP-TLS stores no user password; password-based methods store credentials as described in the certification package, with the migration to hashed companions recorded there. |
| Use the Data Processing Agreement and the published subprocessor list when completing the agency's own privacy and supply-chain review. | Data Processing Agreement and subprocessor list published in the Trust Center. |
10. How to obtain and use this guide (SCG-CSO-AUP)
The current version is public at https://www.ironwifi.com/fedramp/secure-configuration/ (this guide) and https://www.ironwifi.com/fedramp/secure-configuration/secure-configuration.json (the same content as JSON for customers who ingest configuration guidance programmatically). Both carry one version number and effective date and are republished together. The guide is also in the FedRAMP certification package bundle at https://www.ironwifi.com/fedramp/IronWiFi-FedRAMP-20x-ClassA-Package.zip, in the IronWiFi Trust Center at https://trust.ironwifi.com under FedRAMP Documentation, and on request from the FedRAMP Security Inbox, [email protected].
IronWiFi shares this guide with everyone without a decision step: it contains no customer data and no secret. The policies it refers to are released as recorded in the certification package.
To use it, identify your account type (owner or team member), apply section 2 first because it governs all downstream access, then sections 5 to 9 for the tenant configuration. Questions go to [email protected].
11. Public availability (SCG-CSO-PUB)
This guide and its machine-readable form are public: no account, registration or access request is needed at either URL above.
Version history
| Version | Date | Summary of changes |
|---|---|---|
| 1.0 | 2026-09-12 | First publication: recommended tenant configuration for agency deployments in five areas. |
| 1.1 | 2026-09-13 | Restructured to SCG-CSO-RSC: named the top-level administrative account and privileged accounts; added secure access, configuration, operation and decommissioning for the owner account; added settings by permission, secure defaults at provisioning, how to obtain the guide, public availability and this history; added the machine-readable form. The five recommendation tables of version 1.0 are unchanged apart from the API-key capability, which now states that a key is bound to a role and has no customer-set expiry. |