You already have these critical systems to protect. An OpenFlow controller is no different. Put the management systems on an isolated network segment or virtual LAN (VLAN), make sure the controllers are hardened, monitor activity, restrict access to it--all the stuff that you do now.
The other security objection is availability. If an attacker can launch a denial of service (DoS) attack against the controller, then he or she can take out the network. Fair enough. I left this objection for last, because DoS mitigation, to a large extent, is addressed by the same principles of good controller design and existing anti-DoS methods. A good controller design doesn't have every new flow going to the controller for disposition--only flows that are unknown.
I think there is some research needed, but I don't think DoS is going to be that big of a risk. If an attack floods new flows that are guaranteed to miss, such as spoofed off-net IP addresses, then the controller has to deal with them. Send enough of those flows and you have a DoS. But, in a well-designed network, you know what your address ranges already are, so those that are off-net can be black-holed. Routers have had that capability--blocking source IP addresses that are off-net--for years and years. If memory serves, on Cisco's IOS, it's a single global command.
You shouldn't ignore single points of failure and single points of attack in any product or system, and you shouldn't acquire or use a critical system that doesn't offer high availability or quick recovery options. But you need to take these conditions in the context of the criticality of the system and the other systems that can support it.
