My company is currently in the process of rolling out support for the iPhone. As a part of this rollout, they are requiring employees to install an application on their phones that allows IT to push out profiles to the device in order to enforce things such as password locks, backup encryption, etc. However, the application also uses the location services API to report the device's current approximate location (nearest cell tower) as well as general information about the device. It reports back to their management console every time the phone connects to a new cell phone tower. The reason for this requirement is they say that otherwise they cannot always ensure that a device is not jailbroken and thereby potentially bypassing their security policies.


Is the threat of users connecting with jailbroken iPhones a legitimate enterprise security concern? Is it worth the privacy implications of the IT department being able to track the approximate location of employee devices?

  • 6
    It isn't clear to me how having the device "report back to their management console every time the phone connects to a new cell phone tower" enables them to "ensure that a device is not jailbroken." Checking in, good. Checking in with your users' location information, not buying it.
    – gowenfawr
    Aug 9, 2011 at 22:17
  • 1
    @gowenfawr That's a great point. However, I believe this might be a limitation of the multitasking support in iOS. The only way that an application can regularly perform a process such as checking in with the management console is if they use something like location services, which is one of the only APIs that iOS provides for multitasking. Aug 10, 2011 at 4:50
  • If someone is savvy enough, they can always hide the fact that they have a jailbroken device in the environment. Hopefully that person is a pen-tester "white hat" employee or partner.
    – atdre
    Feb 17, 2013 at 10:04

7 Answers 7


In terms of the second part of your question about the privacy trade-off, that's very dependent on the organisation in question and their priorities.

Unfortunately a lot of companies would place their security concerns much higher on an agenda than privacy concerns for their employees (unless regulatory requirements dictate otherwise).

On the first part, there's a couple of potential risks from jailbroken iPhones that I'm aware of.

First would be restrictions on applying updates. There will likely be a delay in being able to apply Apple security updates as the jailbreak won't always be available instantly for that version.

Second would be the concern that the jailbreak or software installed afterwards could compromise the security of the iPhone (eg, the default password on the SSH daemon from jailbroken devices). There can be an assumption of quality and security control for iOS apps installed from the official Apple store that isn't there for apps from other sources.

Also having a jailbroken device may allow the user to disable security software installed by the company, which I'd guess is another reason that they're not keen on it.

  • 1
    Would it be possible to re-word "There can be an assumption of quality and security control for iOS apps installed from the official Apple store that isn't there for apps from other sources." - I know that you're saying Apple isn't malicious; and while they're not malicious I do not trust them or their software. I'll agree that I do trust them more than I trust some random russian malware site which a user visited to learn about jailbreaking.
    – DanBeale
    Aug 10, 2011 at 9:42

Are jailbroken iPhones an enterprise security risk?

Potentially. I think it is hard to determine without data. On one hand, users who jailbreak their phones are typically knowledgeable about computers and mobile devices. They may be less susceptible to phishing and may be more vigilant about their device's security. On the other hand, jailbreaking allows installation of network access applications like ssh, ftp, bittorrent, and other peer to peer programs, that may be used by attackers to threaten the larger system. They may have a higher risk of installing applications with malware.

Is the threat of users connecting with jailbroken iPhones a legitimate enterprise security concern?

It is a concern, but I think that is because the iPhone, as well as any personal networked mobile device, threatens the traditional IT model of operation and control.

Traditionally the IT department made decisions about what equipment to purchase, how to configure it, where to allocate it, and who got to use it. Additionally they were responsible for providing connectivity to the users, administering the services that made the users productive, and supporting the users when they needed help.

Look at what the iPhone (or similar device) does to that model. The user purchased it, configured it (maybe with outside support), and it is permanently allocated and used by the individual. The user obtains connectivity from a outside source, but still wants connectivity with the corporate network.

The IT department no longer has an inherent right to configure it, revoke all connectivity (they can only revoke corporate connectivity), or revoke device allocation or usage. With the prevalence and growing demand for smart phones, it doesn't matter if the iPhones in this case are corporate-owned, as an increasing number of employees will have personal smartphones which present the same issues.

Is it worth the privacy implications of the IT department being able to track the approximate location of employee devices?

I am not a lawyer, but there may be important legal implications depending on the jurisdiction the company is in, and the jurisdiction(s) where the iPhones are used. I suggest seeking appropriate legal advice on this question.

Apart from the legal risk, I think there is a real risk of loss of users' trust in the IT department. In my opinion IT needs the trust of the users. A hardline IT department that acts unilaterally will find itself with a growing insider threat. Users who respect the IT department are more likely to listen to warnings, attend training, and report problems or issues.

  • 1
    Remember that the person who jailbroke the phone need not be the person who operates the phone.
    – user185
    Aug 10, 2011 at 15:10
  • @Graham, huh? As far as I know, it would be extremely rare to find an iPhone that has been jailbroken without the consent of the owner/operator of the phone. I'd question whether that's a realistic risk that merits heavy-handed tactics from the IT department; it sounds like a movie-theater plot to me.
    – D.W.
    Aug 10, 2011 at 22:25
  • @D.W. I think he means that the tools used to jailbreak the phone are not developed by the phone owner, and without checking/inspecting/verifying those tools the phone is effectivly jailbroken by the tool maker. I'm not sure if I agree or disagree.
    – this.josh
    Aug 10, 2011 at 22:49
  • Still sounds like a movie-theater plot. Is there any evidence that the jailbreak tool-makers are planting backdoors that have been used to subvert enterprise security? Smells like FUD to me.
    – D.W.
    Aug 10, 2011 at 22:58
  • There are multiple possibilities here. One I've encountered in the real world is non-technical people being told that jail breaking is better by friends, and allowing said friends to do so. Another that's well-documented is drive-by jailbreaks. A further hypothetical scenario is jail breaking an unattended device. Think for a while and you can come up with more: the person doing the jail breaking is not necessarily the handset owner, as I said.
    – user185
    Aug 11, 2011 at 7:40

This is the input I use to a threat model when discussing the impact of jailbreaking with app makers. Remember that I know nothing about your company, the value of the assets you'll be storing/accessing on your iPhones (to you nor to the attacker), who the attacker might be and so on.

For a non-jailbroken iPhone, I consider that the software on the device is completely under the control of the owner. Opportunities for installing code are restricted to the App Store and an enterprise deployment configuration, if the phone is set up for enterprise deployment.

This means that we can restrict ourselves to vulnerabilities (and the possibility of trojan data-sending features) in deployed apps, and to the data available in these apps. The most likely risk I consider in this situation is losing the handset; either for it to wind up in the hands of an attacker or in an industry with a zero-tolerance policy to data exfiltration. Exploiting an installed app to gain access to the data is a possibility, but I expect it to be unlikely unless your specific user is being targeted. There are better things to make botnets out of than iPhones.

Understanding the threat posture of an installed app probably means asking the vendor for an assessment, and only deploying apps where the vendor can provide such information. How far the vendor is willing to go to get a dollar sale is an open question; a third-party vulnerability assessment may be an option.

As reported in the Fraunhofer Institute paper, some of the data in the Apple-supplied iOS apps is not protected using the file protection facility, because it needs to be used by background services so potentially while the device is locked. This means that on finding a device lying around, such data is accessible to the attacker. However, business content such as mail attachments are not part of this data, and indeed Apple has upgraded the protection status of some of the data since the report was published. Whether data used in third-party apps is protected in such a way can again be discovered via assessing the app.

When data is protected, it can only be accessed (by any part of the OS including the kernel) once the user has entered the correct passcode, so the data protection is consistent with the passcode strength. The way in which iOS derives the protection key from the passcode removes the possibility of offline attacks, and forces online attacks to proceed at very slow rate (with the option of forcing data erasure after a number of failed attempts).

OK, so that's a non-jailbroken iPhone. Now let's consider the transition: how do I jailbreak an iPhone? The first option is deliberate manual jailbreak by the owner, which is the most likely route. In my experience the owner is not necessarily a technical user; they could have been told by a friend or colleague that jailbreaking gives them more control, or more apps via Cydia or similar. Most jailbreak documentation calls on the user to change the default root password, so in this case it is likely that the attacker doesn't know the root credentials for the phone.

The second option is a drive-by jailbreak, using e.g. a PDF vulnerability. This could be either deliberately initiated by the owner, or they could be coerced into visiting a vulnerable file sent for example as an e-mail. The way most jailbreaks work is to modify the bootloader to load a non-OEM kernel. This means that the jailbreak functionality won't be available until the user has rebooted the phone, at which point any unlock encryption keys have been thrown away.

The final option is that the phone is under the control of an attacker who then uses a manual jailbreak technique. This does not require that the attacker know the passcode. After jailbreaking the passcode will still be required to access protected data as the decryption key is derived from that passcode. To retrieve protected data, the attacker will need to return control of the jailbroken device back to the owner. Essentially the attacker needs exclusive access to the phone for around 15 minutes: I consider that unlikely; a social engineering attack (or straightforward theft-and-return) is a small possibility.

So what can be done with a jailbroken iPhone? Conventional wisdom says anything can be done, that the phone's operating system is now as open as a regular desktop OS; but let's consider the likelihood of various scenarios.

For a start, all of the risks associated with a non-jailbroken iPhone still exist.

Installing common third-party remote access or monitoring tools such as sshd can be achieved if they are part of the jailbreak OS image, if the attacker has a route to deploying them onto the phone (say while controlling the device in the last jailbreak route listed above) or if the user chooses or is coerced to install the tool. In the case of sshd, valid credentials for the phone, such as the default root password, must be known to the attacker. Because prepackaged builds of such tools exist, this attack does not require a clever or resourceful attacker. Because the sandboxing restrictions of the stock kernel are lifted for a jailbroken phone, the remote access tool can access all files in all apps - including protected files while the device is unlocked.

The attacker could, through similar mechanisms to that for installing stock tools, deploy special software such as a Trojan version of an existing app, or custom malware like event loggers and uploaders. This is a more technically-advanced version of the same attack, and because it doesn't really offer much benefit to the attacker over using standard tools I consider it much less likely. The (ab)use case for this attack would be where an app uses its own internal authentication and crypto protocols, and the attacker needs to acquire the user's in-app credentials or otherwise view the in-app content that never appears to the rest of the OS in a readable way.

So the conclusion is that there are more risks associated with jailbroken iPhones than stock iPhones: indeed the attack surface of a jailbroken phone is a superset of the attack surface of the stock phone. Is that important? As I said at the top, it depends on your users and your assets.


Is the threat of users connecting with jailbroken iPhones a legitimate enterprise security concern?

Yes it is. As @marknca excellent iOS security guide states:

When a device is using a jailbroken version of iOS, it can run any Objective-C code it desires. This means that all of the iOS API protections can no longer be counted on. Therefore allowing jailbroken devices in your corporate deployment poses a significant risk as they are not forced to comply with the technical controls you've put in place. Jail-breaking leaves forensic artifacts on the device that can be detected during analysis but this does not help is maintaining the integrity of your network since you have to have possession of the device in order to perform this analysis. The current crop of MDM—Mobile Device Management—vendor supports various forms of detecting jailbroken devices over the air. As with jail-breaking itself, this is a constant back and forth game of detection and concealment."

There are a number of mitigations for reducing the risk of jailbroken iPhones:

  • Use Mobile Device Management (MDM) software that can detect jailbreaks (cat and mouse game as stated above)
  • Use a VPN to access corporate resources. Minimize sensitive resources stored on the device
  • Use an application like the one from Good technology to create an encrypted sandbox on the device and only allow corporate data on this application and it's partition

I provide more detail on these strategies here: http://www.rakkhis.com/2010/07/iphone-and-android-securely-in.html

Is it worth the privacy implications of the IT department being able to track the approximate location of employee devices?

Note none of the above strategies required tracking of the device location. As far as I can see none of the stated risks above with a jailbroken phone is mitigated by tracking location. Whether intentional or not, it could result in an employee backlash as it is seen as tracking their location for behavioral or productivity purposes.

Designing location services for security and privacy is not a simple challenge. If the company believes there is a legitimate reason and communicate this clearly to employees then it should be able to abide by the following principles:

  • Notice and consent - users need to be clearly informed and their permission explicitly obtained (i.e. not just rely on employment contracts fine print)
  • Security - the data needs to be protected, usually encrypted
  • Purpose - data used only for the purpose that consent is provided
  • Access - users should have a simple option to delete the information collected

I did a presentation on this topic and the slides are here: http://www.slideshare.net/rakkhi/designing-location-services-for-privacy

  • It was my assumption that they are using the location services API so that they can check on a regular basis whether the iPhone is jailbroken or not. Do you know for sure that MDM would let them pull enough data from the device, without surrendering location data, to be able to check on a regular basis whether or not the phone is jailbroken? Can this all be done with location services completely disabled for their management application on the device? Aug 10, 2011 at 16:08
  • I don't understand these claims about the risks of jailbroken iPhones. The paragraph quoted seems like marketing speak, and thoroughly unpersuasive. What's your threat model? What exactly is the risk you are worried about?
    – D.W.
    Aug 10, 2011 at 22:23
  • @chris-jackson I have looked into MDM before that will detect a jailbroken iphone and report this back to a central management console (or take any other per-defined action) without sending the location of the phone. I don't see how the 2 need to be linked
    – Rakkhi
    Aug 11, 2011 at 15:45
  • @d-w think about it for a bit. Well basically any client side control you put e.g. lockout after 10 failed password attempts can be turned off on a jailbroken iphone. If this phone allows access to corporate resources e..g Email via an SSL VPN, and the phone gets lost or stolen, your data has possibly been compromised
    – Rakkhi
    Aug 11, 2011 at 15:45
  • @Rakkhi I agree that they shouldn't need to be linked. However, with location services turned off, I was curious if the application could still do a periodic check. I don't believe a normal application could do it, however I'm not very familiar with MDM to know if it can do the check without needing a local application on the device that has location service enabled. Aug 11, 2011 at 16:35

Your question touches on a problem many organizations are struggling with. On one side the organization wants to give employees access to data, on the other they want to make sure the data is protected.

Is it a legitimate enterprise concern? The answer is it depends. It depends on what data would be available on the device and it depends on the risk associated with the data. It also depends on the companies contractual and legal obligations.

If it is your phone and the company has not compensated you in any way for the phone purchase or voice/data then there is a simple solution: Do not use your personal phone for business purposes. If your company needs you to have a phone then make them purchase a phone to be used only for business purposes and rock the batman utility belt look.


You can view this the other way around.

Does the security of the services provided rely on the integrity of the remote device.

If it does then that is a serious concern, as this opens an attack vector into the network from any device that purports to be an iPhone.

  • And importantly, in this case it is also a serious concern for non-jailbroken iPhones.
    – D.W.
    Aug 10, 2011 at 22:25

" ... Is the threat of users connecting with jailbroken iPhones a legitimate enterprise security concern? ..."

Yes. It may sound strange, but the fact that Apple has a strict reign over the app store can be considered as a security control implemented by a 3rd party.

"... Is it worth the privacy implications of the IT department being able to track the approximate location of employee devices? ..."

First I would challenge the assumption that knowing the location of a person using a (company) phone can detect a jailbroken iphone. Doesn't make imediate sense to me. If still functionality cannot be disabled, I would suggest to restrict the access to this information to a very small group of persons within the company. This is very personal information, even more so than e.g. the web browsing history. And last but not least I would suggest to communicate this fact in a very clear manner.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .