Security
Fieldmark® holds research data that often cannot be collected a second time. The measures below are in place today.
Hosting and infrastructure
The hosted Fieldmark service runs on DigitalOcean, in an Australian data centre. That is the default and it is a deliberate choice, made so that research data stays onshore unless a customer asks otherwise. Other locations are negotiable where a project requires them.
Enterprise clients who require it can have Fieldmark deployed on AWS instead, scoped in their agreement (may affect costs and default storage limits). Self-hosted Enterprise, which runs on your infrastructure and is operated by our team, is also available.
Data in transit, and who can see what
Data moving between the Fieldmark app, the Dashboard, and the servers is encrypted in transit using Transport Layer Security (TLS).
Access is controlled by digitally signed tokens, and authorisation is role based. The roles a person holds in a notebook or a team are set by an administrator rather than by the person themselves.
Each notebook keeps its records in a database of its own, which admits only accounts that hold a role on that notebook, so an account sees only the notebooks it has been given access to.
Where a password is used, a third-party password-strength library enforces a minimum strength rather than a length rule alone.
Backups
The hosted service is backed up every day. We keep each daily backup for 7 days, one a week for 4 weeks, and one a month for 12 months, so data can be restored as it stood on any day in the past week, at weekly points over the past month, and at monthly points over the past year. Enterprise deployments on Amazon Web Services keep a daily backup for 30 days instead. Backups are held separately from the machine they came from, so losing that machine does not lose the backups with it.
Recovery does not depend on the backups alone. The servers, their software and their configuration are defined as code and rebuilt from it, so a full recovery is a rebuild plus a restore of the data. That is deliberate: a rebuilt system starts from the code, not from a copy of the old machine, so changes made on that machine itself, such as a manual misconfiguration or an intruder’s foothold, are not brought back as they would be by restoring a disk image.
A more detailed account, written for procurement, ethics and IT reviewers rather than developers, is on the backup and recovery page.
Independent security testing
The Fieldmark platform has been penetration tested by an external firm, Sekuro Operations, engaged by a client of ours. Testing ran from 3 to 13 March 2025 and the report was issued on 20 March 2025. The scope was a system built on the platform: its Android application, its web application, and its interface (API).
The test returned no critical findings, one high, five medium, and nine low. The high finding and all five medium findings have been remediated, and the fixes are recorded in our update notes, which we can supply with the report.
Two recommendations were assessed and the risk formally accepted rather than the change implemented: obfuscation to hinder tampering, which adds little to a codebase that is already open source, and a stricter local password policy beyond the enforced minimum, with reliance placed on the third-party sign-in providers instead. A stricter policy has since been added: every Fieldmark password must now pass an automated strength check.
We test the Fieldmark web application, mobile applications, and servers periodically.
Monitoring and maintenance
Errors in the production service are reported to Bugsnag and reviewed by the development team. The hosting platform runs health checks against the running components and alerts the team when a deployment or a domain check fails.
We track dependencies with GitHub’s security alerts and automated updates, and work through open alerts with the critical ones first.
External uptime checks run against the production API from several regions. We do not publish an availability figure yet, but plan a status page in future.
Signing in
You can sign in to Fieldmark with a Google account, with your Australian university credentials through the Australian Access Federation (AAF, of which Electronic Field Notebooks is a subscribing member), or with a Fieldmark username and password. Okta has been integrated and is deployed in production for an enterprise client, and other single sign-on configurations are available for enterprise deployments, including OIDC and SAML.
On the hosted service, accounts are created by invitation. There is no open self-service registration, so an administrator decides who joins a server and what they can do there. An enterprise deployment can instead create accounts automatically when people first sign in through the institution’s single sign-on. Whether it does, and what a new account can do, is set for each deployment. Fieldmark does not synchronise with an institution’s directory (through SCIM or LDAP, for example).
On an Enterprise deployment, everything we set up on our cloud follows the practices on this page. Your institution controls sign-in when it uses its own identity provider, and can switch off Fieldmark passwords; your own administrators decide who joins each notebook.
Vendor review and insurance
We have completed a HECVAT (Higher Education Community Vendor Assessment Toolkit), the questionnaire universities use to assess vendors. It is an assessment, not a certification.
Electronic Field Notebooks holds cyber-risk insurance.
Reporting a security problem
If you find a security problem in Fieldmark, tell us before you tell anyone else, and we will work the fix with you. We will acknowledge your report, keep you informed whilst we investigate, and credit you when the fix ships if you would like us to.
Send the details, including how to reproduce the issue, to [email protected], and put “security” in the subject line so it is triaged first. The same address is served at /.well-known/security.txt with a contact line, a preferred-languages line, and an expiry date.