Security You Can Check, Not Just Trust
Every IoT platform describes itself as secure, and the descriptions are interchangeable because none of them can be checked. This page takes a different approach: it says what ioX-Pulse actually does, in terms specific enough that you can verify each one in a trial account before you believe us.
That covers three things. How somebody gets in, and what stops the wrong person. How your customers are kept apart from each other. And what record exists afterwards of everything anyone did.
- Multi-factor authentication you can require across your workspace, with a grace period
- Passwords that appear in known breaches are rejected at the point somebody chooses one
- Three failed sign-in attempts lock an account
- Session length is yours to set, and shortening it reaches sessions that are already open
- Sign-ins, device changes, member changes and settings changes are all recorded with who and when
- Revealing a device's keys is itself an audited event
The front door
Getting In: Passwords, Second Factors and Lockout
Most breaches are not clever. They are a reused password, or an account nobody switched off. The controls here are aimed at that reality rather than at an imagined adversary.
| Control | What it does |
|---|---|
| Password rules | A minimum length in double figures, with mixed case and a number. Passwords that appear in known breach corpora are rejected when somebody tries to choose one, rather than being accepted and regretted later. |
| Multi-factor authentication | Available to anybody, and you can require it across your workspace. A grace period gives people already using the platform time to enroll. Recovery codes are issued at enrollment and are the way back in if somebody loses their phone. |
| Customer-level policy | A customer can require multi-factor inside their own account even if you have not required it across yours. Where the two policies differ, the stricter one applies. |
| LockoutDELIBERATE | Three failed sign-in attempts lock the account, and unlocking it goes through support rather than an email link. |
| Session length | You set how long a session survives inactivity, from minutes up to a day. Shortening it applies to sessions that are already open rather than waiting for the next sign-in. |
Trusted by customers across multiple industries
Who did what, and when
Every Change, Recorded
The audit log is a read-only record of what happened and who did it. It exists for the moment somebody says a device has gone missing and you need to know whether it was removed, by whom, and when.
| Recorded | Detail |
|---|---|
| Sign-ins | Both successful and failed, so an attempt that did not work is visible as well as one that did. |
| Device and gateway changes | Registered, assigned, edited or deleted. |
| Member changes | Invitations, role changes, suspensions and removals. |
| Settings changes | Including changes to security settings themselves. |
Each entry records who did it, the exact time, and what changed. Entries generated by the platform rather than a person are marked as such. The log can be filtered and exported, which is what you want when a question has become a dispute.
If you run accounts for customers, your own view is a roll-up across all of them, and you can also open any single customer's log on its own. The log is limited to administrators.
