JCIM
JCIM led
- Connection and security architecture
- Support-process integration
- Implementation and delivery direction
Proof unit 01 · Bosch Building Technologies · EffiLink
Replacing a disappearing network standard with a secure remote-service foundation
When ISDN was withdrawn, Bosch needed more than a technical replacement. It needed a secure, operational way to connect service technicians with safety-critical installations at customer sites.
01Customer siteinitiates
02Outbound tunnelTLS / CERT
03Service-case gateexplicitly approved
04Techniciantime bounded
OUTBOUND ONLYCERTIFICATEFAIL CLOSED
JCIM / INDUSTRIAL SYSTEM EVIDENCEREF 01–A
01Controlled outbound
02Certificate-based
03Fail closed
Evidence typeDEEP CASEEvidence strength: MODERATE
The challenge
- The previous remote-access model depended on ISDN and could not simply be transferred to an IP environment.
- The systems were safety-critical. Direct inbound access, uncontrolled parallel sessions and static credentials were not acceptable.
- Earlier internal efforts had produced requirements and partial ideas, but no working end-to-end service model.
What JCIM did
- 01
JCIM restructured the initiative around a working first proof rather than another requirements cycle.
- 02
JCIM designed the overall connection architecture so that the customer-side system initiated the secure connection and access was enabled only for a valid service context.
- 03
JCIM integrated the platform with the existing support and workforce-management environment, allowing the surrounding business process to determine who could do what and when.
- 04
JCIM held responsibility for the implementation architecture and delivery direction; Bosch supplied the physical hardware components.
- 05
The security model combined controlled outbound connectivity, certificate-based authentication, explicit session approval and fail-closed behaviour.
Responsibility boundary
BOSCH
Bosch / partners brought
- Physical hardware components
- Operational and service context
- Product and field expertise
DEPENDENCIES
Partners / external dependencies
- Existing support/workforce system
- Available certificate and network boundaries
- Approval of the service case
Buyer contribution
- Physical hardware components
- Operating and service context
- Product and field expertise
What changed
A functioning first release was established within a few months.
Remote commissioning, diagnosis and maintenance became operationally possible without exposing installations to uncontrolled access.
The first proof created the technical and organisational foundation for the later EffiLink rollout and service expansion.
Evidence
Before state → After state
Before state
→The ISDN-based remote-access model was disappearing.
After state
A functioning first release connected security, access and operating process.
Before state
→No working end-to-end service model existed for the IP environment.
After state
Remote commissioning, diagnosis and maintenance became operationally possible.
Before state
→Direct inbound access and static credentials were not acceptable.
After state
The release formed the foundation for later rollout.
- Controlled outbound access
- Explicit session approval
- Fail-closed behaviour
06
Human Logic
The decisive adoption condition was control. Service, IT and security teams did not need to ‘trust the cloud’; they needed a system in which access existed only inside a valid service case and could be interrupted immediately.
Transfer conditions
Transferable when …
- The customer site may initiate a controlled outbound connection.
- Access can be bound to a valid service case and identity.
- Product, IT and service owners work against the same boundary.
Not directly transferable when …
- Outbound connectivity is prohibited in principle.
- No viable identity, certificate or approval context is available.
08
What this proves
This case shows JCIM’s core pattern: reduce a complex industrial transformation to the smallest real proof, then connect technology, security and operating process so the proof can become a service.
- Technology, security and service process can be connected in one controlled mechanism.
- A small working proof can form the foundation of a later service.
09
What this does not prove
- The case is not an outcome, timeline or scale guarantee for another programme.
- It does not demonstrate future revenue, ROI or universal economics.
NEXT PROOF
Test whether your access, identity and service-case boundaries permit the same controlled mechanism.
We will identify the smallest real proof that can turn uncertainty into a controlled management decision.