The App Was the Side Door
An organization that required single sign-on, approved devices and an office network had secured the browser and nothing else: the phone reached the same records from anywhere. Since 14 October the workspace security policy governs the AWRA app too, at sign-in and on every request after it.
A security policy is only as strong as the least-guarded way in. For most of this year, an organization could set AWRA to accept sign-ins only through its identity provider, only from the office network, only from approved devices, with sessions that expire after an idle half hour — and every one of those rules applied to the browser. The app on a field officer’s phone answered to none of them.
Nobody did anything wrong to create that. The web had a session, a middleware chain and a settings page, and the policy was built there. The app arrived later with its own sign-in and its own tokens, and it was correct about everything it checked. It simply did not check the policy.
That is closed. The same six rules now apply when someone signs in to the app and on every request the app makes afterwards.
Six rules, two places they are enforced
A rule checked only at sign-in can be outlived: a phone signed in on Monday inside the office keeps working from a matatu on Thursday. A rule checked only per request lets someone be handed a token that fails on its first use. So the network and device rules are checked at both points, and the session limits are checked every time the app presents its token.
| Rule | At app sign-in | On every app request |
|---|---|---|
| Sign in only through your identity provider | Password, emailed link and passkey refused; provider sign-in passes | Not needed: no token exists without it |
| Password expiry | An expired password is refused and a reset link emailed | Not needed: the token was issued after the check |
| IP allowlist | Refused before a token is issued | Refused; the session is kept for when the phone is back on an allowed network |
| Device approval | A new install is held for an administrator | A locked or revoked install is signed out |
| Idle timeout | Not applicable | A token unused for longer than the limit is deleted |
| Absolute session lifetime | Not applicable | A token older than the limit is deleted, however recently it was used |
Two of those answers were chosen for what the person holding the phone experiences. Stepping off the office Wi-Fi onto mobile data gets a clear refusal, and stepping back on just works: the network was wrong, not the person, so the app does not sign them out. A device that has been locked or revoked is different — the token is deleted and the app returns to its sign-in screen with the reason.
A phone is an install, not an address
The web recognises a device by its browser signature and address. That works tolerably for a laptop on a desk. It does not work for phones: two staff with the same model of Android phone look identical, and a phone’s address changes with every mast it passes on the road from Thika.
So the app now identifies itself by its install — an identifier created when the app is installed and sent with every request. With device approval switched on, the first sign-in from a new install is held. The administrator sees it on the device trust screen labelled as the AWRA app, the person gets a bell notice that the device is waiting, and the refusal is written to the audit log. Once approved, that install works; a different phone, or the same phone after a reinstall, asks again.
Before you switch device approval on
An app build old enough not to send an install identifier cannot be told apart from any other phone, so where approval is required it is refused with a message asking the person to update. Ask your team to update the app from Google Play first, and expect a short queue of approvals on the first morning.
Biometric unlock is convenience, not a longer session
The app lets people unlock with a fingerprint or face rather than typing a password each time. Underneath, that unlock exchanges a long-lived biometric credential for a fresh short-lived access token. It is a genuine re-authentication — the person proved they hold the phone and the finger — which is why it satisfies the idle limit: unlocking is exactly what an idle timeout asks for.
It does not satisfy the absolute limit. That is counted from when the credential was created, and it applies to the biometric credential as well as to every access token minted from it. If your organization sets a twelve-hour ceiling, the fingerprint stops working twelve hours after the person last signed in properly, and from then on they sign in again through whatever method your policy allows. Without that, a credential that never expires would mint new sessions forever, and the ceiling would mean nothing on the one device most likely to be lost.
An idle limit asks whether the person is still there. An absolute limit asks when they last proved who they are. A fingerprint answers the first question and not the second.
Single sign-on means single
The rule that mattered most is the plainest. An organization that requires its identity provider does so because that is where it switches people off: when a staff member leaves, one account in the directory is disabled and access everywhere should end with it. If the app still accepted a password or an emailed link, a departing employee who had never been asked to use either could still sign in on their phone, outside the directory’s reach.
The app now refuses every method except the provider sign-in for those organizations, and says why. Accounts that are deactivated, past their access end date or belong to someone offboarded were already refused on the app, at sign-in and on every request; this closes the case where the account is still live in AWRA but the directory has moved on.
Where these settings live and how the device list works is set out on device trust and security operations; the app itself is on the Android app page.
Ask any vendor whose product has an app
If we require single sign-on, can someone still sign in to the app with a password?
A good answer sounds like
No — the app runs the same sign-in rules as the browser.
What it tells you
If the answer is about the web settings page, the app has its own rules.
How do you tell one phone from another for device approval?
A good answer sounds like
An identifier per app install.
What it tells you
Browser signature and address cannot separate two identical phones on mobile data.
Does a fingerprint unlock reset our session lifetime?
A good answer sounds like
It resets idle time, never the absolute limit.
What it tells you
Otherwise a lost phone keeps a session for as long as the thief has the finger, or the PIN.
What happens to a phone already signed in when we add an IP allowlist?
A good answer sounds like
Its next request outside the list is refused.
What it tells you
A rule checked only at sign-in waits for the next sign-in to apply.
What AWRA OpsHub does today
- Single sign-on enforced in the app: where your organization requires it, password, emailed-link and passkey sign-in are refused and only the provider sign-in passes.
- Password expiry enforced in the app: an expired password is refused at sign-in and a reset link is emailed.
- IP allowlist on every app request, checked before a token is issued and again on each call, without signing the person out when they return to an allowed network.
- Device approval per app install: a new install is held until an administrator approves it, with a bell notice to the person and an entry in the audit log.
- Idle and absolute session limits on app tokens, with biometric unlock counting as activity for the idle limit and never extending the absolute one.
More we can add to your workspace
- Session limits per role, so a cashier’s phone and a finance manager’s phone can carry different idle and absolute limits. The policy is one per workspace today.
- An IP allowlist per role or per person, for field teams who legitimately work from mobile data while head office stays on the office network.
Where we point you to a specialist
- We do not manage the phone itself. Remote wipe, operating-system restrictions and app-store control belong in a mobile device management tool, and AWRA’s device approval sits alongside one rather than replacing it.
- We will not exempt the app from a policy your organization set. A rule that applies to the browser applies to the phone, including on the day it is inconvenient.
Per-role limits and per-person network rules are scope rather than ceilings: the policy, the checks and the device list exist, and each is a written specification and a price.
If you switch on device approval or an allowlist, tell your field staff the day before, and have the administrator who approves devices on hand that first morning.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur take
If your organization requires single sign-on or approved devices, look at the device trust screen this week: every phone signed in to the app is now listed as an install, and every one that signs in from here on answers to the same rules as the browser. A policy that stopped at the browser was a policy with a side door. The door is shut.
See the device list your administrators approve
Single sign-on, password expiry, an IP allowlist, device approval per install and session limits — set once for your workspace, enforced in the browser and in the app.
Explore device trustFrequently asked questions
Does our security policy apply to the AWRA mobile app?
Yes, since 14 October 2026. Single sign-on only, password expiry, the IP allowlist, device approval, the idle timeout and the absolute session lifetime all apply to app sign-in and to every request the app makes, not only to the browser.
How does AWRA identify a phone for device approval?
By the app install. The app sends an identifier created when it was installed, so two identical phones are two devices, and a phone changing networks stays the same device. A reinstall is a new install and needs approving again.
Does unlocking the app with a fingerprint extend the session?
It counts as activity for the idle timeout, because unlocking is a re-authentication. It never extends the absolute session lifetime, which is counted from when the credential was created and applies to the biometric credential too.
What happens when a signed-in phone leaves the allowed network?
Its requests are refused with a message saying the address is not on the allowlist. The session is kept, so the app works again as soon as the phone is back on an allowed network, without signing in again.
Will older versions of the app keep working with device approval on?
No. A build too old to send an install identifier cannot be recognised, so where approval is required it is refused and the person is asked to update the app. Without device approval it works as before.
