Security & privacy
Four checks behind every tap.
A tap isn't trusted — it's verified. Each clock-in is checked against up to four signals before it lands in your records.
The checks run in the server, not on the phone.
- Proof 1Plaque signature SUN valid ✓
- Proof 2Phone session Known person ✓
- Proof 3Venue network IP match ✓
- Proof 4GPS position Asked · none given
The four proofs
What each signal proves, and how.
Moment, person, place — and a backup for place, for when the network can't answer.
One-time signature
The plaque's NTAG 424 DNA chip signs every tap with a fresh counter + AES cryptogram. Copied or replayed links are rejected — you must physically be at the plaque, right now.
A link that works once
On every read the chip writes a fresh link: the plaque's id, a counter that only goes up, and a 16-character signature (CMAC) made with the plaque's AES-128 key.
The server checks the signature, then moves the plaque's counter forward in one database statement that refuses to go backwards. A second use of the same link finds the counter already at or past it and is rejected.
Plaque keys are stored only in encrypted form, under a separate key.
- 000641Last accepted read
- 000642Accepted — the counter moves to 000642
- 000642The same link again — rejected
- 000640An older link — rejected
Phone session
Identity lives in a secure session on each employee's own phone, behind their own screen lock. No shared PINs, no swappable cards — the phone has to be there.
One phone, one person
A phone gets its session through activation: the employee opens their invite link, agrees, and makes a first real NFC tap at one of your plaques. That tap writes no record; the next one clocks in.
The phone keeps a random 256-bit token. The database keeps only a keyed hash of it, so the stored value cannot be used to sign in.
When you switch someone off, their next tap is rejected and the attempt is logged as a security event.
- 01Opens the invite link
- 02Agrees on this phone
- 03First NFC tap at your plaque
Site IP match
Requests from your site's WiFi carry its static IP — hard evidence the person is inside the building.
A network list too wide to mean anything is ignored
The address that counts is the one the request arrives from, checked against the ranges saved for the plaque's venue. The Wi-Fi name is not evidence.
A list of ranges stops counting once it is too wide to stand for a single network: more addresses than a /7 holds in IPv4, or a /31 in IPv6. A wider list is refused when you save it and is not counted when a tap is judged. Inside that limit, keep the list to your venue's own connection.
- Within the limit — up to a /7's worth of addresses: can count as proof of place.
- Too wide — refused when saved, not counted when a tap is judged.
GPS fallback
WiFi down or phone on mobile data? GPS confirms presence within 150 m (the default radius). Anything unverified is stored, flagged, and queued for manager review — by default, never approved without evidence.
One position, only at the tap
The tap page asks the phone for its position once, when the button is pressed. Nothing reads it in the background, before or after.
The radius is a deployment setting, 150 m by default. A position inside it counts as proof of place; by default, a position outside it sends the tap to a manager, even if the network matched.
A QR check-in has no signature, so by default a position alone is not enough for it: it needs the venue's network.
- Inside — counts as proof of place.
- Outside — sent to a manager by default, even with a network match.
The decision
Built-in rules first, your rules next, a person last.
Nothing is approved by default. When no rule decides a tap, it is flagged for a manager.
- Plaque not in service REJECTED
- Signature fails, or the counter did not move REJECTED
- No session on this phone activation page · nothing recorded
- Account switched off REJECTEDsecurity event
- Same person again within 60 seconds IGNORED
- Venue network matched, or GPS inside the radius APPROVED
- GPS read, but outside the radius FLAGGED
- QR code without the venue network FLAGGED
- Neither network nor GPS FLAGGED
- No rule above decided the tap FLAGGEDqueued for a manager
- Every tap
- 20
- Venue network
- + 50
- GPS inside the radius
- + 30
Every record carries this score. It is shown on the record and decides nothing: the rules do.
Debounce is per person
A queue of people can tap the same plaque one after another, and every tap is recorded. Only the same person tapping again within 60 seconds is ignored.
The 60 seconds are timed on the server's clock, so a phone's clock cannot shorten them.
Five of the eleven guardrails are shown. The others include rules that refuse a tap page that is too old, refuse a declared time that is implausible, keep a plaque of a business outside your group out of your records, hold a QR scan at a partner business to that venue's own network and keep rule changes to an owner. Your rules also flag a tap whose declared time is well in the past or a tap after reads of the plaque the server never saw, and note a tap at another of your venues without judging it. The 60-second window and the 150 m radius are deployment settings; the figures shown are the defaults.
When the evidence is thin
Flagged, never dropped.
Anything unverified is stored, flagged and queued for manager review; by default nothing is approved without evidence.
Drawn for this page — sample names and times.
- A manager decides each flagged record once, and the decision cannot be changed afterwards.
- Until then its hours are held out of the total, and The Roll shows them as waiting.
- The decision is stored beside the record; the record itself never changes.
Corrections
Records are never edited. Corrections are new records.
The application has no permission to change or delete a stored record, and a guard in the database refuses the database owner's account too; switching that guard off would take a deliberate change to the database itself, or a database superuser.
When a shift needs fixing, a manager adds an entry by hand. It is marked “Entered by a manager”, stays apart from tapped records in reports, and the action is written to an audit log.
Manual entries, marked apart from tapped onesPrivacy
No fingerprints. No tracking. No ad cookies.
No fingerprints, no face scans
None collected, everNothing in the product reads a finger or a face. The phone's own screen lock stays the phone's.
No background location
GPS is read only at the moment of the tap. Nothing follows the phone between taps.
No ad or analytics cookies
Taptime sets no advertising or analytics cookie, and its public pages load nothing from another site.
Privacy by design: Taptime stores no fingerprints, no face scans, and never tracks location — GPS is read only at the moment of the tap. Built for GDPR from day one.
Isolation
Every business is walled off in the database itself.
Every record of a business carries that business's id, and row-level security in the database filters every query by it. In production the application refuses to start under a database role that could switch that filter off, and its queries name the business a second time.
Taptime's support console has its own sign-in, separate from yours. Every read it makes into an account is written to an operator audit log first, and every change it makes to an account is written there in the same transaction as the change: no change is stored without its entry.
The one crossing between businesses is a group Taptime sets up for companies that belong together: their staff can clock in at each other's venues, and the record lands with the person's own employer. The venue they clocked in at sees the name, the time, the direction and the outcome, never the location evidence. With the API switched on, each company in the group can also list the others' staff: their names, codes and external references, and whether each is active.
When counted taps are sent to your own systems by webhook, every delivery is signed: its X-Taptime-Signature header is an HMAC-SHA256 of the body under your endpoint's own key.
Hosting & GDPR
Where Taptime runs.
Hosted in the EU (Germany)
Taptime's production server runs in Germany.
Built for GDPR from day one.