Export Control Compliance for Space Tech: What Cloud PDM Can and Cannot Do
How EAR and EU dual-use rules affect space-tech data, which cloud PDM controls can help, and which duties remain with exporters.
Setting Up Access Control: Who Should See What in Your PDM System
A practical guide to PDM access control—covering RBAC, least privilege, an access matrix by engineering role, supplier sharing via Guest access, quarterly access reviews, and what CAD ROOMS supports across Business and Enterprise plans.
TABLE OF CONTENTS
Access control in a PDM (Product Data Management) system defines who can view, edit, approve, and share engineering data based on role, project, and file scope. Effective PDM access control rests on two industry principles: least privilege (grant only what a role needs) and role-based access control (RBAC, meaning permissions attach to roles rather than to individuals). For engineering teams, this usually means three layers of access: workspace administration, project-level engineering work, and file-level external sharing with suppliers. This guide covers how to define those roles, build a practical access matrix, safely open data to suppliers, review permissions on a schedule, and what CAD ROOMS supports today.
What Access Control Means in PDM
A PDM system stores the most sensitive assets in a hardware company: CAD models, BOMs, engineering change orders, and manufacturing documentation. Access control determines whether each user, contractor, and supplier can reach those assets, and what they can do once they get there.
Without properly configured access control, a few recurring problems show up on engineering teams. Someone with overly broad permissions accidentally shares a sensitive assembly with the wrong colleague or partner. A contractor whose project ended six months ago still has an active account. Engineers waste time hunting for the current revision because every project in the workspace appears in their sidebar. In regulated industries, unclassified users can reach controlled data, and it surfaces later during an audit.
Good access control fixes these without locking engineers out of their work. Each person sees the data their role actually requires, and not much more.
Least Privilege and RBAC
Two industry principles anchor almost every PDM access control model.
Least privilege means granting each user the minimum access they need to do their job. NIST defines it as giving users "the least set of privileges necessary to perform authorized tasks." In engineering terms: a purchasing manager reviewing BOMs does not need edit access to CAD assemblies; an intern working on a single bracket does not need visibility into the full product portfolio.
Role-Based Access Control (RBAC) attaches permissions to roles, then assigns users to roles. The NIST RBAC model formalized this approach in the 1990s and it remains the dominant permissions model in enterprise software, including PDM.
RBAC pays off in a few practical ways. Onboarding is faster because adding a new engineer is a single role assignment. Access stays consistent because everyone in the same role has identical permissions, which removes a common source of small errors that accumulate over time. And a single change to a role updates every user in it at once, so you don't touch each account individually.
Two related practices strengthen an RBAC model. Separation of duties ensures the person who creates an engineering change request is not the same person who approves it. Regular access reviews catch permission creep, contractors who kept access after a project ended, and employees who changed roles but retained old permissions. Quarterly is a practical baseline for most engineering teams.
Least privilege is a foundational access-control principle, but it does not by itself establish compliance with any regulatory or security framework such as ISO 27001, SOC 2, ITAR, or GDPR. Compliance requires broader controls (documented policies, evidence of enforcement, incident response, and independent audit) that go beyond how permissions are structured. See our guide to cloud PDM security standards for framework-specific requirements.
The Five-Step Permission Design Flow
Designing PDM permissions is not a one-time configuration. It is a repeating loop that works whether you are setting up permissions for the first time or reviewing an existing setup.
- Map the data. List the types of data your team stores in the PDM system: in-development CAD, released CAD, BOMs, ECOs, manufacturing drawings, supplier deliverables. For each type, identify who needs to see it, who needs to modify it, and who must never see it.
- Assign roles. Translate the data map into role assignments at the workspace and project level. Assign the smallest reasonable role for each user's job. Reserve Project Admin for engineering leads who genuinely need to manage project membership, and keep the Workspace Admin count small.
- Test visibility. Log in as a representative user for each role and confirm they can reach what they need and cannot reach what they should not. This is the single most-skipped step and the most common source of both security incidents and workflow complaints.
- Review permissions on a schedule. Run the quarterly access review (see the checklist below). Access drift is inevitable; scheduled review is what keeps it from compounding.
- Revoke or adjust. When a review or event (contract end, role change, project close) surfaces access that is no longer appropriate, revoke or adjust it promptly. This includes Guest access previously granted to external parties; CAD ROOMS does not automatically expire it.
Run the loop against your real users, not against the org chart. Job titles rarely map cleanly onto access needs.
Access-Control Matrix by Engineering Role
A concrete way to plan PDM permissions is to build an access matrix that maps roles to what they can do with engineering data. A minimal matrix for a CAD team looks like this:
Role | View project files | Upload / edit files | Manage project members | Approve ECOs | Manage workspace |
Workspace Owner | Yes | Yes | Yes | Per ECO assignment | Yes |
Workspace Admin | Yes | Yes | Yes | Per ECO assignment | Yes |
Workspace Member | Per project role | Per project role | Per project role | Per ECO assignment | No |
Project Admin | Yes | Yes | Yes | Per ECO assignment | No |
Project Collaborator | Yes | Yes | No | Per ECO assignment | No |
Project Viewer | Yes | No | No | No | No |
Guest (external) | Shared files only | No | No | No | No |
Two points about this matrix are worth calling out. First, Reviewer and Approver are not platform-wide roles. They are responsibilities assigned inside a specific engineering change order (ECO). A Project Collaborator can be an ECO approver on one change and a reviewer on another, depending on how the change workflow is configured. Second, Guest is fundamentally different from Viewer: a Viewer is a project member with read-only access to that project's files, while a Guest is an external user with read-only access to specific files that have been shared with them, without workspace or project visibility.
Internal Users versus Suppliers
The rules that govern internal team members are not the same as the rules that govern suppliers, contract manufacturers, and external design partners.
Internal users belong to the workspace and receive access through workspace and project roles. Seat requirements depend on their role and the current plan. For an internal engineer, the right default is Project Collaborator scoped to their active projects, with Project Admin reserved for engineering leads who manage member access and project settings.
External users should not have workspace or project membership at all. Suppliers, contract manufacturers, and consultants only need to see the specific files relevant to their scope of work. In CAD ROOMS, this is handled through Guest sharing: guests receive file-level, read-only access to the exact files shared with them and do not see the workspace, project structure, or other project files.
Before each supplier share, run through a six-item checklist. This is a team practice, not an automated system behavior:
Purpose: what is the business reason for this share, and how long is it needed?
Files: exactly which files does this supplier need? Share only those; do not add the supplier as a project member.
Revision: is this the correct released revision, not a work-in-progress version?
Download need: does the supplier actually need to download, or is view-only sufficient for the task?
Re-review or revoke date: when will this share be reviewed or revoked? CAD ROOMS does not automatically expire guest access, so put a reminder on the team calendar. Expiry is a team practice, not a platform behavior.
Audit trail: does this engagement need a record of what was shared, to whom, and when?
Guest sharing is a technical control that works alongside NDAs and export-compliance processes, not instead of them. This article covers permission design and review only. For the operational side of supplier relationships, including handoff, revision control, and communication protocols, see our guide to secure supplier collaboration. For export-controlled data (ITAR, EAR), see export control compliance for hardware companies. For framework compliance (ISO 27001, SOC 2, GDPR), see cloud PDM security standards.
Access Reviews and Offboarding Checklist
Access control drifts over time. The single most effective mitigation is a documented review cadence combined with an offboarding checklist.
Quarterly access review:
Review the list of workspace members and confirm each is still active.
Review Project Admin assignments—these are the highest-privilege project role and warrant the most scrutiny.
Review Guest access granted in the previous quarter and revoke any that is no longer needed.
Confirm that contractors and consultants have access only to projects tied to active engagements.
Review the workspace-level admin count and keep it small.
Offboarding checklist (employee or contractor departure):
Remove the user from the workspace on their last day.
Reassign any Project Admin responsibilities they held.
Revoke any external file access they previously granted, or reassign it if the engagement continues.
Review the available audit events for unexpected activity during the user's final working period (Business Plan and above).
Update SSO or identity-provider records so the account cannot be re-enabled.
Automation helps, but the review cadence is the actual control. Systems that promise to "handle it automatically" without human review usually accumulate the same drift they were meant to prevent.
What to Verify with Any Cloud PDM Vendor
Access-control language varies widely across cloud PDM vendors. Before committing to a platform, verify the following in writing or in a live demo. These questions apply to any vendor, not just CAD ROOMS.
- Permission scope: does the vendor's permission model apply at the workspace, project, folder, or file level? Confirm specifically whether external users are added as project members or scoped to individual files.
- Download control: who can download files, and can download be restricted for specific roles or specific external users?
- External-user visibility: when you share a file with an external partner, what else can they see? Project name, folder structure, other file names, other users?
- Permission revocation: who can revoke access (workspace admin, project admin, or the person who shared), at what granularity (a single file vs. an entire project), and does revocation take effect immediately?
- Audit log coverage: which events are recorded—logins, downloads, permission changes, guest-share creation, guest-share revocation? For how long are logs retained, and can they be exported?
- Plan boundaries: which access-control features are gated behind higher plans (Business, Enterprise, or equivalents)? Design your permission model around what you can actually use on your current plan.
Get clear answers to these before migrating a project into a new PDM platform. Assumptions that turn out to be wrong after migration are expensive to fix.
What CAD ROOMS Supports (and Where Plan Boundaries Apply)
CAD ROOMS structures access control in three layers aligned with the model above:
- Workspace roles — Owner, Admin, Member. Workspace roles control billing, member management, and workspace-level administration. See Understanding Roles and Permissions.
- Project roles — Project Admin, Collaborator, Viewer. Project roles control what users can do with files, ECOs, and collaboration tools within a specific project.
- Guest sharing — file-level, read-only external access. Guests do not receive workspace or project visibility; they only see the specific files shared with them. See Guest Sharing.
ECO approval is a project-level workflow, not a standalone platform role. Reviewers and approvers are assigned inside a specific engineering change order; the platform does not have a global "Approver" role.
Plan boundaries to keep in mind when planning a rollout (see CAD ROOMS pricing for current details):
- Business Plan includes Advanced Permissions, Audit Logs, and ECO review and approval workflows.
- Custom Roles & Permissions and SAML SSO are available for Enterprise configurations, for organizations that need a tailored permission model or centralized identity management.
If your team needs audit logs or ECO approval for compliance reasons but is on a plan below Business, plan the upgrade before designing your permission model around features you cannot yet use.
Ready to Set Up Access Control in Your PDM?
Use this article as a shortlist checklist: workspace and project roles, guest sharing scoped to files, ECO review and approval, audit logs, and a documented access-review cadence. Book a live demo to see how CAD ROOMS handles each of these for your team, or compare plan boundaries on the pricing page.
Frequently Asked Questions (FAQ)
Q: What roles should a PDM system include?
A: A practical PDM permission model has three layers: workspace-level administration, project-level engineering access, and external file sharing. In CAD ROOMS, that maps to workspace roles (Owner, Admin, Member), project roles (Project Admin, Collaborator, Viewer), and Guest sharing for external partners. Reviewer and Approver are not standalone platform roles—they are responsibilities assigned inside a specific engineering change order. Keep the total number of roles small so the model stays easy to audit and easy to explain to new team members.
Q: What is the difference between a Viewer and a Guest?
A: A Viewer is a project member with read-only access to that project's files—they can see the project, the file tree, and everything in it, but cannot upload or modify. A Guest is an external user who receives file-level, read-only access only to the specific files shared with them; guests do not see the workspace, the project structure, or other files in the project. Use Viewer for internal stakeholders like executives; use Guest sharing for suppliers and contract manufacturers.
Q: Can suppliers access CAD files without seeing the full project?
A: Yes. CAD ROOMS Guest sharing grants an external user read-only access to specific files without adding them as a project member. The supplier sees only the files you explicitly share; they do not see the workspace, the project structure, or any other files. This lets you collaborate on the components a contract manufacturer needs to build without exposing the rest of the design. Pair guest sharing with a signed NDA and, where relevant, export-control checks.
Q: Who can approve an ECO in CAD ROOMS?
A: In CAD ROOMS, designated Reviewers can comment on, approve, or reject an ECO. Project Admins and Collaborators can create, edit, and comment on ECOs, but approval authority depends on being assigned as a Reviewer for that ECO. Viewers and Guests can read ECOs and their comments, but they cannot approve or release them. ECO management and approvals are available on the Business Plan (see CAD ROOMS pricing).
Q: How often should PDM access be reviewed?
A: A quarterly access review is a practical baseline for most engineering teams. Each quarter, confirm workspace membership is current, review Project Admin assignments, revoke guest shares tied to completed engagements, and check that contractors have access only to active projects. Pair the quarterly review with an offboarding checklist that removes the departing user, reassigns Project Admin duties, and revokes any external file access they previously granted. Audit logs (Business Plan and above) help identify unusual activity between reviews.
References
- NIST — Role-Based Access Control (RBAC): Features and Motivations
- NIST CSRC — Least Privilege (glossary)
- CAD ROOMS Help Center — Understanding Roles and Permissions
- CAD ROOMS Help Center — Guest Sharing: Secure External Collaboration
- CAD ROOMS — Pricing
About the author
Christina Rebel
CEO of CAD ROOMS | Co-founder of Wikifactory
I'm Christina Rebel, CEO of CAD ROOMS. For over a decade, I've worked at the intersection of cloud engineering collaboration, digital manufacturing, and distributed product development.
Throughout my career, I've worked closely with engineers, designers, and manufacturing teams to improve CAD data management, version control, supplier collaboration, and browser-based design review. My focus is on making modern engineering workflows more accessible, secure, and efficient, particularly for SMEs and startups. I also write about engineering collaboration, with contributed articles published by Design News and DEVELOP3D.
Follow the author: LinkedIn
Related Articles
- Cloud PDM Security: Protecting Your IP from Data Breaches and Theft
- How Encryption Protects Your CAD Files in the Cloud
- Data Security Standards for Cloud PDM: ISO 27001, SOC 2, GDPR
- How to Evaluate Cloud PDM Security: A 2026 Checklist for Hardware Teams
- Approval Workflows That Don't Slow Down Innovation
- Secure Supplier Collaboration for Distributed Engineering Teams
Related Posts
Cloud PDM security comparison 2026: protecting your engineering data
Compare cloud PDM security specs, external access models, and pricing across CAD ROOMS, SOLIDWORKS 3DEXPERIENCE, Onshape, OpenBOM, and Autodesk Fusion Manage.
Cloud PDM Security: Protecting Your IP from Data Breaches and Theft
How can you protect your IP from data breaches and theft? A guide to cloud PDM security.