Access control across Aras, Windchill, Teamcenter and 3DEXPERIENCE: one question explains it

Every platform will tell you it has fine-grained, role-based access control, and every one of them does. Comparing feature lists gets you nowhere, because the lists are identical. The difference is architectural, and it comes down to a single question that decides how each of the hard access scenarios behaves:

Does access attach to the item, or to the container the item lives in?

That is the axis. Everything below follows from it, so it is worth stating each platform's answer plainly before the scenarios, because the answer is the prediction.

• Aras Innovator — access attaches to the item. Every item instance carries its own Permission, a default from its ItemType that is overridable per item, so a child part in a BOM can hold a different permission from its parent (Aras WebHelp, About Permissions).
• PTC Windchill — access attaches to the domain and context. ACLs are computed from domain policy rules keyed on object type plus lifecycle state plus participant, and every product, library, project and organization is a context with its own team and policies (PTC, Access Control Overview).
• Siemens Teamcenter — access is decided by a global rule tree. Access Manager evaluates IF-condition-THEN-named-ACL rules top to bottom, first match wins, with an object-level ACL able to override, plus Projects and a separate export-control layer on top.
• Dassault 3DEXPERIENCE / ENOVIA — access attaches to the collaborative space. A user's effective rights are a security context of Role × Organization × Collaborative Space, and every object is stamped with an owning space (GoEngineer, Understanding Collaborative Spaces).

One platform binds access to the object. Three bind it to a container the object sits in. Hold that distinction and the scenarios below stop being a feature comparison and become predictable.

A disclosure, up front: we implement on Aras. The competitor mechanisms here are cited from vendor documentation and practitioner references; where a claim rests on a single source or could not be fully verified, it says so.

The four scenarios

Read the table by column and the pattern is stark: the item column has no caveats. Three of the four scenarios that a manufacturer actually hits are a non-event for Aras and a mechanism-with-caveats — or a licensed module — for everyone else. Now the detail, because it is even more one-sided up close.

S1 — the supplier who may see only part of the assembly

This is the scenario that separates the item model from the container model most sharply, because it asks for something a container model resists: expose the parent, hide a child.

Aras does this natively, because permission is a property of the item. The child part you want hidden simply carries a Permission that excludes the supplier, independent of its parent. Aras also separates two privileges most platforms merge — Can Discover from Get. Discover lets an identity know an item exists and see limited grid data without opening it; Get grants the full form (Aras discovery docs). So you can even choose whether the supplier sees that a hidden node exists or not.

Windchill has no dedicated partial-BOM feature. Because Read is required to see any object at all, you achieve it by denying Read on the specific child parts — and there is a documented limitation: a user denied Read on a part version still sees that part's Master node in the product structure, a gap that has been an open request on PTC's own ideas forum (PTC Community). True concealment usually needs customisation or a purpose-built export.

Teamcenter also has no structure-aware branch-hiding feature. You restrict a supplier to specific parts by attaching Authorized Data Access licenses to the sensitive components, or by scoping an external company through a Partner Connect contract that hides everything outside it. Workable, but per-object rather than a property of the tree.

3DEXPERIENCE exposes objects by sharing them into a space the supplier can read. Because sharing is object-scoped, showing a sub-assembly without its siblings or parent means deliberately sharing each chosen item rather than masking a subtree — the same container-model friction.

Verdict on S1: Aras native, the other three achieve it by per-object denial or a separate mechanism, with Windchill carrying a specific documented gap. This is the clearest single win in the comparison, and it follows directly from the item-versus-container axis.

S2 — two projects sharing one sub-assembly

Here the container model catches up, because every platform has some concept of putting one object in two places.

Aras is again a non-event: the shared sub-assembly carries its own permission granting both project teams, while each project's higher assembly keeps a permission that hides it from the other. No sharing mechanism required, because there is nothing to share — the item was never owned by a container.

Windchill does it through sharing: adding a part to another project creates a link to the latest iteration of the source object, not a copy, and exposes only that object, not its parent (PTC, sharing objects). The source project must have sharing enabled, and a shared object is not added to the project baseline — a caveat that trips up some downstream tooling.

Teamcenter assigns the single object to multiple Projects and uses an In Project accessor. It works, but because Access Manager is one global top-down tree, a broad project rule can leak across projects, so cleanly isolating several projects that share components tends to need carefully ordered per-project sub-rules rather than one generic rule.

3DEXPERIENCE maps this cleanly through ownership vectors: an object has one primary owning space plus optional secondary vectors, so the shared sub-assembly carries secondary vectors into two spaces while each top assembly stays in its own Private space.

Verdict on S2: the others need a sharing mechanism; Aras needs none. Windchill must create and govern a share, with the baseline caveat behind it. Teamcenter must assign multiple projects and then fight its own top-down rule tree to stop one project's access leaking into another. 3DEXPERIENCE must attach a secondary ownership vector. Each works, and each is a mechanism an administrator configures and maintains. In Aras there is nothing to configure, because the sub-assembly was never owned by a container in the first place — its permission simply names both teams. The others reach the same destination; Aras is already there.

S3 — external identity, and what it costs

Split this into two questions, because they have different answers.

Authentication is near-parity. All four federate to an external identity provider over SAML: Windchill through Shibboleth with PingFederate now bundled in the licence and SCIM for provisioning; Teamcenter through Security Services; 3DEXPERIENCE through 3DPassport; Aras as a SAML service provider and with its own OAuth 2.0 authorization server (Aras DevOps docs). One honest note that applies to everyone: OpenID Connect is not clearly a first-class documented path on Windchill, Teamcenter or 3DEXPERIENCE — SAML is the evidenced route across the board. So on protocols, a slight Aras edge for shipping its own OAuth server, but broadly even.

The cost of external access is where they diverge, and it echoes the licensing argument in the Aras-versus-Windchill paper. Aras uses an enterprise subscription with unlimited named users and no per-seat charge, so a supplier identity adds no licence cost (Aras subscription). The others treat external access as a licensed thing: Windchill models suppliers as organization participants with an External User entitlement; Teamcenter delivers external access through separately licensed products — Teamcenter Share, Supplier Collaboration Foundation, Partner Connect; 3DEXPERIENCE external collaborators either consume their own platform licences or are given branded role licences on yours.

Verdict on S3: level on authentication, decisively Aras on cost. Every platform can authenticate a supplier over SAML — that part is a tie and we will not pretend otherwise. But on the three others, giving that supplier access is a licensed event: an External User entitlement, a separate collaboration product, a consumed role. On Aras it is free. For a manufacturer with a large and constantly changing supplier base, "free to add a supplier" versus "licensed per supplier" is not a rounding error — it is the line that grows every year in the renewal.

S4 — access that changes with lifecycle state

This is the scenario everyone wins, and it is worth saying so rather than manufacturing a difference.

All four bind access to lifecycle state natively. Windchill puts lifecycle state directly in the access-rule antecedent, so permissions change automatically on promotion. Teamcenter keys Access Manager rules on release status and adds workflow-stage ACLs. 3DEXPERIENCE governs it through maturity states, with an elegant Protected space type where data is private until it reaches Released. Aras carries State Permissions on the lifecycle map that override the item's normal permissions while it is in that state.

Verdict on S4: a genuine wash — and we will say so plainly, because conceding the tie is what makes the other three verdicts believable. Any platform that could not do this would not be in the conversation. The only footnote worth adding is that Aras expresses it the same way it expresses everything else — as state permissions on the lifecycle map, configuration the administrator owns rather than a rule tree a specialist maintains — but the capability is table stakes, and no one should be sold S4 as a differentiator.

Where the others are genuinely stronger

A comparison that ends "and so Aras wins everything" is a brochure. Two honest concessions, both real:

Teamcenter for hard export control. Teamcenter's Authorized Data Access is a purpose-built, separately licensed layer for IP and ITAR — IP_License and ITAR_License classify objects, Exclude_License denies named users and access is checked against a user's clearance level, administered by dedicated IP and ITAR admin roles. For a defence programme that must satisfy an auditor with a decades-old ITAR pedigree, that is the more battle-tested answer, and it would be dishonest to pretend otherwise. But notice how narrow the concession is. Aras's Mandatory Access Control policies gate on item classification versus user clearance, citizenship and location — the same export-control shape, built in rather than separately licensed — and for any manufacturer that is not under active ITAR audit, which is most of them, that covers the ground without buying a module. The concession is real; it just describes a smaller room than it first appears to.

3DEXPERIENCE for a single-vendor design world. The collaborative-space model plus maturity states is coherent and mature, and if your organisation lives entirely inside the Dassault stack, the ownership-vector mechanism is elegant for exactly the S2 sharing problem.

The through-line

Look back at the four verdicts and the pattern is not "Aras is more secure." All four platforms are secure — none of this is about weak mechanisms. The pattern is that the platform whose access attaches to the item handles the item-shaped problems without a module, and the item-shaped problems — a supplier who sees one branch, a component shared between two walled projects — are the ones a real manufacturer actually hits.

The container model is not wrong. It is often cleaner for the container-shaped problem: "everyone on this project sees everything in this project" is beautifully expressed by a Windchill context or a 3DEXPERIENCE space. The mismatch only appears when the requirement cuts across the container — expose the parent, hide the child; share the child, hide the parent — and those are precisely the supplier and multi-project scenarios that prompt the question in the first place.

So the buying question is not "which has better access control." It is: how much of your real access need is item-shaped rather than container-shaped? If the answer is "a lot" — and for a manufacturer managing suppliers and shared platforms it usually is — the item model is doing for free what the container models do with per-object rules, separate modules and licensed external seats.

That is the same argument that runs through the permissions design paper: the model you can reshape without a module or a code change is the one that survives contact with an organisation that never stops changing.

For a manufacturer whose access problems are item-shaped — suppliers who see one branch, platforms shared across projects, an ever-changing external base that must cost nothing to admit — the honest tally is three clear wins and one tie, and the one tie is a capability every platform has. That is not marketing. It is what falls out of a single architectural choice: bind access to the item, and the item-shaped problems stop being problems.

---

Working paper, written by a consultancy that implements on Aras. Platform mechanisms are as documented in August 2026; Windchill claims are cited from PTC's own Help Center, while some Teamcenter and 3DEXPERIENCE internals are cited from practitioner references where the vendors' primary documentation is login-gated. If you think we have described any platform unfairly, tell us and we will publish the correction.