Home / Security / Security overview for Teams and Enterprise
Security overview for Teams and Enterprise
Version 3.0, last updated November 1, 2026. This document describes how MedLicense protects the credentialing data of a shared workspace, and it is written so that it can be attached to a vendor security questionnaire. The setup steps for administrators are in the IT setup guide.
1. Summary
- MedLicense has no server. The software runs on your people's devices, and the shared workspace is a folder in your own Microsoft 365 (SharePoint or OneDrive for Business).
- Every file in the workspace is encrypted on the device with AES-256-GCM before it is uploaded, so Microsoft stores only ciphertext and the MedLicense company never receives, stores or processes your data.
- Who can open the folder is decided by SharePoint permissions that your administrators control. What each person can do inside the app is decided by workspace roles, and every change is recorded in a signed audit log.
- Sign-in uses Microsoft Entra ID, so your existing multi-factor authentication and conditional access policies apply.
2. Architecture in words
A workspace is a folder that your IT team creates in SharePoint or OneDrive for Business and shares with your credentialing staff. The MedLicense app on a Mac, Windows PC, Android phone or iPhone signs the person in with Microsoft Entra ID, receives a delegated Microsoft Graph token, and reads and writes files in that folder through graph.microsoft.com. There is also an advanced mode in which the OneDrive or SharePoint sync client keeps the folder on disk and MedLicense reads and writes it as an ordinary folder, which needs no Graph permissions.
The folder contains these items:
workspace.json, a small plaintext manifest holding the workspace name, tenant ID, key epoch, the public intake key and the license key.workspace.hlv, the encrypted workspace document with every provider, credential, request and setting.blobs/, encrypted copies of the scanned documents, each named by the SHA-256 hash of its content.members/, one small JSON file per member, holding that person's name, email, role, device public keys and the workspace key wrapped to each of their devices. It contains no secrets, only public keys and wrapped keys.join/, pending requests from people asking to join.audit/, encrypted and signed audit entries, one file per member per month.intake/, where providers' encrypted document packages arrive, andkeys/, which holds the encrypted intake private key.
Data flows in one direction only: from the device to your Microsoft 365 tenant, and back to the devices of your own members. The only other network request the app makes is the optional NPI lookup to the public NPPES registry at npiregistry.cms.hhs.gov, which sends only the NPI number that the user typed.
Providers who are being credentialed are not members and never receive the workspace key. A coordinator sends them a signed request, and the provider's own free MedLicense app (or any browser, using an upload link) sends the documents back in an encrypted package that only the workspace can open.
3. Encryption
| Purpose | Algorithm |
|---|---|
| Encrypting files and records | AES-256-GCM, with a random 96-bit nonce for each seal. The sealed file format is called HLV1. |
| Device key agreement | ECDH on NIST P-256. |
| Deriving keys | HKDF with SHA-256, using the workspace ID or request ID as salt and a fixed label as info. |
| Signatures | ECDSA on P-256 with SHA-256, stored as 64-byte raw values. |
| Content addressing | SHA-256. |
| Personal recovery passphrase | PBKDF2-HMAC-SHA256 with 310,000 iterations, used for an individual's own vault and not for shared workspaces. |
The workspace key. A workspace has one 32-byte random key that seals the workspace document, the document blobs, the audit files and the intake private key. It is never stored in plaintext in the cloud folder.
Wrapping the key to each device. Every device that joins generates two P-256 key pairs, one for encryption and one for signing, which never leave the device. To give a device the workspace key, an existing admin generates a fresh ephemeral P-256 key pair, computes ECDH with the device's public encryption key, derives a 32-byte wrapping key with HKDF, and seals the workspace key with it. The result is stored in the member's record. Because the ephemeral key is discarded, the wrapped value can only be opened by the intended device.
Joining. A new device writes a join request containing its public keys. A six-digit code is derived from the device's public key, and the joiner reads it to an owner or admin by phone or chat. The administrator types the code to approve, so a request that was planted by someone with folder access cannot be approved without the person's voice. Requests expire after 24 hours, and three wrong codes reject the request.
Provider intake. A provider's package is encrypted to the workspace's intake public key using an ephemeral key, ECDH and HKDF with the request ID as salt, so each package has its own key and only the workspace's intake private key can open it.
4. Key management
Device private keys and the cached workspace key are held in the platform's secure store and never written in plaintext to the cloud folder.
| Platform | Secure store |
|---|---|
| macOS and iOS | Keychain. |
| Android | Android Keystore, which wraps the key file. |
| Windows | DPAPI, bound to the signed-in Windows user. |
The app can additionally be locked with Face ID, Touch ID, Windows Hello or the device biometric. Enterprise workspaces can require that app lock is set up on a device before the workspace will open. The Microsoft access token for a workspace is stored in the same secure store, separately from a person's personal OneDrive token.
Rotation. When a member or device is removed, an admin rotates the workspace key. The app creates a new key, wraps it to every remaining device, re-seals the workspace document, the intake key and the current audit files immediately, and re-seals the document blobs in the background. A removed device cannot unwrap the new key. The previous key is kept sealed under the new one only until the background pass finishes.
5. Roles and access control
Access is enforced in two layers, and we describe both honestly.
- SharePoint permissions are the hard boundary. Your administrators decide who can open the folder at all. Viewers should be given Read permission, so that their devices cannot write.
- Workspace roles decide what the app shows and permits. A person who holds the workspace key could in principle read the files directly, so the roles are an application-level control that complements SharePoint, not a replacement for it.
| Capability | Owner | Admin | Coordinator | Viewer |
|---|---|---|---|---|
| See providers and reports | Yes | Yes | Yes | Yes |
| See the audit log | Yes | Yes | No | No |
| Add or edit providers, credentials and documents, send requests, build packets | Yes | Yes | Yes | No |
| Reveal or export private details such as a date of birth | Yes | Yes | Only if the workspace policy allows | No |
| Approve joins, change roles, remove members | Yes | Yes, except owners | No | No |
| License, policies, key rotation | Yes | Yes | No | No |
| Delete the workspace | Yes | No | No | No |
Only providers (the people being credentialed) count toward license seats, and coordinators, viewers and admins are free. On the Enterprise plan, administrators can set workspace policies: require app lock, restrict private exports to admins or disable them, refuse join requests from outside the workspace's Entra tenant, set default reminder windows and add a confidentiality footer to exported PDFs.
6. Audit log
Every create, update, delete, reveal, export, print, send, request, import, join, approval, removal, role change, license change, policy change and key rotation is recorded as an audit entry containing the time, the member, the device, the action and a one-sentence summary. Summaries never contain private values such as a date of birth or a Social Security number.
Each entry is signed with the acting device's ECDSA signing key. Entries are written to a file that only that member's devices write (one file per member per month), which avoids write conflicts and means a member cannot silently rewrite someone else's history. Readers verify each signature against the public signing key in the member record, and the Audit screen marks any entry that does not verify. Reveals and exports of private details are always logged. Enterprise workspaces can export the log as CSV.
The audit log is tamper-evident for a reader who holds the workspace key, not tamper-proof: a person with write access to the folder could delete an audit file. SharePoint's own version history and your Microsoft Purview audit logs provide an independent record of file activity.
7. Data residency and retention
All workspace data resides in the SharePoint or OneDrive location that your organization chose, in your Microsoft 365 tenant and in the data-residency region of that tenant. MedLicense the company has no copy. Retention, backup, legal hold and eDiscovery are governed by your own Microsoft 365 settings, and because the content is ciphertext, those tools will see encrypted files and not the records inside them. Exports made by the app (PDF, CSV, ZIP) leave the encrypted workspace when a person creates them, and they are then under the control of whoever holds the exported file.
When a license ends the workspace is read-only, and the data remains viewable and exportable. Deleting a workspace removes its files from the folder after the owner types the workspace name, and your normal SharePoint recycle bin rules then apply.
8. Subprocessors
MedLicense the company uses no subprocessors for workspace data, because it never receives that data. The services involved are:
- Your own Microsoft 365 tenant, which stores the encrypted files and provides sign-in. This is your existing vendor relationship and not a subprocessor of ours.
- The public NPPES NPI Registry (
npiregistry.cms.hhs.gov), which is queried only when a user chooses NPI lookup and receives only the NPI number or search text that was typed.
The marketing website loads fonts from Google Fonts, which is unrelated to the apps.
9. HIPAA note
MedLicense the company never receives, stores or transmits protected health information (PHI) from a workspace, because there is no MedLicense server and all data stays on your devices and in your Microsoft 365 tenant. For that reason we do not consider MedLicense a business associate for workspace data. The data in a workspace is credentialing information about clinicians, such as licenses, DEA registrations, certifications and documents, and it is not patient data. Each customer should confirm how this applies to its own situation with its compliance team. This document is not legal advice, MedLicense is not HIPAA-certified, and the app's encryption does not replace your organization's own safeguards.
10. Vulnerability disclosure and incident contact
Security contact: [security contact to be added]
Please report suspected vulnerabilities to that contact once it is published, and give us reasonable time to respond before disclosing publicly. Because MedLicense holds no customer data, an incident at the company cannot expose your records directly. The more relevant risks are a flaw in the app's cryptography or a compromised build, and we would notify customers who hold a license key if either were found.
11. Known limits
- A removed member keeps files they already downloaded. Rotating the workspace key protects everything written after the removal, but it cannot reach into a device that holds old copies and the old key. This is why offboarding must also remove the person's SharePoint access.
- Roles are an application control. Anyone who holds the workspace key and has write access to the folder is technically able to bypass the app. SharePoint permissions, with Read for viewers, are the enforcement boundary.
- Pre-release note: the Microsoft Graph storage backend is implemented to specification but has not yet been tested against a production Microsoft 365 tenant. The synced-folder backend is exercised by our automated tests.
- No independent security assessment yet. The code has not had a third-party penetration test or audit.
- Device compromise. Malware on an unlocked device that runs MedLicense can read what the signed-in person can read. We rely on the platform's secure storage, app lock and your device management.
- Requirement data. The state license and CME rules in the app were compiled for convenience and must be confirmed with each board.
- Exports are plaintext. PDFs, CSV files and packets that a person exports are not encrypted.
12. Questionnaire FAQ
Do you support single sign-on? Yes. Sign-in is through Microsoft Entra ID, so your own SSO, multi-factor authentication and conditional access policies apply. There is no separate MedLicense password.
Do you support SCIM or automatic user provisioning? No. Members join with a six-digit code and an administrator approves them, and removal is done by an admin in the app together with your SharePoint permissions.
Where is our data stored? In the SharePoint or OneDrive location you choose, in your Microsoft 365 tenant. MedLicense the company stores nothing.
Is data encrypted at rest and in transit? Yes. Files are sealed with AES-256-GCM on the device before upload, and all network traffic uses TLS to Microsoft and NPPES. Microsoft also encrypts your tenant storage at rest, as a second layer.
Who holds the encryption keys? Your members' devices. MedLicense the company never has them, so we cannot recover a workspace for you.
Do you have SOC 2, ISO 27001 or HITRUST? Not yet. The architecture means that no data is held by a vendor-hosted service, which removes most of what those reports normally cover, but we do not have a report to give you.
Have you had a penetration test? Not yet.
Do you sign a BAA? MedLicense never receives PHI, so a business associate agreement should not be needed. Please confirm with your compliance team.
Is there an audit log? Yes, signed per device and exportable as CSV on the Enterprise plan.
Can we restrict who can export private data? Yes, with the Enterprise policy for private exports.
What happens if we stop paying? The workspace becomes read-only after the grace period and remains viewable and exportable, so your data is never held hostage.
What happens if MedLicense disappears? The data format is documented, the files are in your tenant, and installed apps keep working, so you keep access to everything you have already stored.
Does the app use analytics or telemetry? The apps do not send usage data to MedLicense, because there is no MedLicense server to receive it.
Can we run it in a sovereign or government cloud tenant? We have not tested this, and the app currently signs in against the commercial Microsoft cloud.