IFC Viewer Online · Back to the BIM & IFC blog
Delivery & ISO 19650 · 2026-11-13 · 7 min
Who Sees Which Model: Keeping Suppliers' Data Apart in a Delivery CDE
A delivery workspace holds models from many companies who must not see each other's work. Five questions to ask any CDE that receives models, and the tests we ran on ours before calling it ready.
Delivery log of a project with 16 entries, the SHA-256 of each file and the chain recalculated in the browser and found intact
A contractor's delivery workspace is an odd place. The structural engineer, the MEP installer and the façade company all deliver into it, and each one is, on another project, the other's competitor. They must see the requirements and their own work. They must not see each other's.
ISO 19650-5 sets out a security-minded approach to managing sensitive information on built assets, whether or not the project uses BIM. [iso-19650-5] You do not need to apply the whole standard to ask a CDE five plain questions.
Key takeaways
- What does a supplier link show, and what does it not?
- What can each role in the receiving team do, and what is refused?
- Can one company ever read another company's data?
- Is the file that was checked the file that was delivered?
- If someone edits the record afterwards, does it show?
1. What a supplier link shows
A supplier link carries a token for one supplier. On its own it shows nothing. With the project it was made for, it shows that project's requirements and that supplier's deliveries, never another supplier's.
We say this plainly because we got it wrong first: while building the upload page, our tests found that the token alone listed every project of the company. It was fixed before the page was merged, and a test now checks it on every run.
2. What each role can do
Inside the contractor's team there are six roles, from owner to guest. Our tests have every role try every write and expect exactly what the role allows. A few examples of what is refused:
- A reviewer can see deliveries but cannot accept or return them.
- A guest cannot see deliveries at all.
- A viewer cannot place an email in the outgoing queue.
- Only owners and admins can change the company's rule library.
When two people edit the same issue or ruleset at once, the second one gets the current copy and a conflict, instead of silently overwriting the first.
3. One company never reads another
Our tests create a second company on the same server and try to read and write the first one's deliveries, issues and rules with its own users. Every attempt is refused. The test runs with the others, so a change that breaks it does not go unnoticed.
4. The file checked is the file delivered
The supplier's browser computes the SHA-256 of the file and registers it before uploading. The validation runner checks that fingerprint and the IFC header before it opens anything: a file that changed on the way, or one that is not an IFC, is returned before validation. The person who decides sees the same fingerprint, and their decision is sealed with it.
Local test of the workspace on our own server with the Hotel Vela test models (real IFC files), Spanish interface. Not open yet.
5. A record that shows if it is edited
Every delivery and every decision is a line in the log, with the date, the author and the fingerprint, chained to the line before. "Check the chain" recalculates every hash in your browser; in our test project, 16 entries matched. If someone edits a line, the chain breaks at that line. The UK BIM Framework describes review and acceptance as a step of the party that receives the information; [uk-bim-part-c] this log is the evidence of each acceptance.
Local test of the workspace on our own server with the Hotel Vela test models (real IFC files), Spanish interface. Not open yet.
What leaves the workspace
- Webhooks are signed with HMAC-SHA256, so your system can tell they came from us.
- Emails go to a queue and wait there. A contact who never agreed, or who unsubscribed, is refused by the queue itself.
- Client links store only the hash of the token and of the password, expire, can be revoked and lock after 10 failed attempts.
What is not done yet
- It runs on our own server in tests, not yet as a hosted service with a contract.
- There is no external security audit yet.
Ask the same of any CDE
These five questions work for any tool, ours included. For the questions an IT department asks about the free viewer (where files go, cookies, sub-processors), see the BIM tool IT security checklist. To test Reception on a real project, talk to us.
Who Sees Which Model: Keeping Suppliers' Data Apart in a Delivery CDE